Re: [gtk-list] Re: [ethereal-dev] Re: gtk-1.2.6 + AIX 4.3.2 == coredump

[Valdis Kletnieks vt edu]

On Sat, 06 Nov 1999 23:29:16 EST, Craig Rodrigues said:
> This hypothesis turned out to be correct.
> For some reason, when libgtk is built under AIX, it does not
> link libgdk.  So, when gdk_check_init() is called from within
> libgtk, the program will segfault, because the reference to
> the function cannot be resolved.  It looks like the flags to
> link libgdk to libgtk are missing from the Makefile.

Actually, that's not why you're segfaulting.. ;)
 
> This was DAMN tricky to find out, because for some insane reason,
> someone decided to include an AIX-specific flag called -berok in libtool.
> Under AIX, -berok tells the linker, "if you are linking stuff
> together, and you encounter unresolved symbols, don't worry about it,
> and build a binary anyways".  So, a binary was being built with
> unresolved symbols...and this binary would crash at run-time, because
> it was not resolving symbols properly.

Actually, if you make this screw-up, the program doesn't crash, because
you get a runtime linker error message.
 
> libtool is a mess. :)

Under AIX 4.3.2, .so format shared libraries are supported in a
slightly odd manner.  The problem is that you have to use the '-brtl'
flag to allow runtime linking.  Failure to do so will result in a
program that *links*, and *loads*, but SEGV's in "can't happen"
places.  The problem is that without -brtl, the run-time binder doesn't
do fully correct TOC relocation for references to entries in .so's.  If
you 'dbx' the program and 'stepi' through it, you'll find it loading
the address of (for instance) an 'extern int', getting a (usually) -1
isntead of a valid address, and then getting a SEGV while dereferencing
it, while you say "but that extern int is defined RIGHT THERE, and
SHOWS UP when I run 'nm' on the binaries"...

Also, make sure bos.rte.bind_commands is at level 4.3.2.4 or later, so you pick up this important fix:

---
APARTXT IX89428 = (AIXV43 only) Runtime linker may incorrectly fail a load
 Applications using runtime linkin may not complete relocation,
 producing illegal instruction or segmentation fault failures.
---

Failure to have this fix on will cause .so format files to lose, even if
you DO have -brtl specified.  Got that? You need the fix, and -brtl,
or .so format shared libs won't work.  I blew two weeks figuring that one out.;)

The local fix I use is as follows:  Add code in ltconfig for AIX >= 4.3.2,
down around line 1500.  It looks like this:

archive_cmds="\$CC $shared_flag"' -o $objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bexpall ${wl}-bnoentry${allow_undefined_flag}'

Arrange to have -brtl added to archive_cmds.  

The other major fuckage of this is that when you link against the
binary, you *again* have to pass -brtl (or otherwise it won't get
called by the runtime linker).  This is a royal pain in the ass, I found
that adding '-brtl' to the end of the  'LINK = yadda yadda' lines
in Makefile.in were your best bet.  I did NOT go and add the -brtl
to the appropriate places in 'automake' files, because I have things
that use automake that don't deal with libtool objects and thus dont need -brtl.

Also, while you're using a can opener on libtool, make sure it uses
/bin/ld directly to build things, and not $CC - this saves linking a
copy of crt0.o into the shared lib, causing duplicate symbol messages.
I *think* recent libtools have this fixed, but it's 2AM.. ;)

Final gotchas:  /usr/sbin/slibclean is your friend.  Also, read
the 'man ld' pages VERY carefully regarding how run time linking works.
If IBM had provided a way to access .so shared libs *without* all the
other baggage taht -brtl implies, this would be a lot easier...

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech