On Wed, 05 Apr 2006 16:13:22 PDT, Rick Jones said: > yep, the compiler (invoked as xlc_r now since this is threaded) has > stopped complaining. Alas, I still segfault at the end of my test. It > looks like my g_module_open()ed library may be dying right at a call to > a routine that is actually in the program itself. Having just learned > that doing that is not possible in a DLL under Windows I'm left > wondering if there are issues with that under AIX > > rick jones > > # ./netperf > Segmentation fault(coredump) > # dbx ./netperf core > Type 'help' for help. > [using memory image in core] > reading symbolic information ... > > Segmentation fault in glink.fflush at 0xd1fda988 ($t1) Oh joy. ;) There's some odd bletcherousness in the AIX linker and dynamic loader, bordering on true evil. The basic problem is that if you do the following: 1) Link libfoo.so -lbar -lbaz where libbar.so and libbaz.so are also shared libs. 2) then link main program cc -o main main.c -lfoo *and omit -lbar -lbaz* It's possible for it to link successfully at compile time, but at runtime, what happens is: a) main gets loaded. b) libfoo.so gets loaded, and calls from main to libfoo.so are relocated. c) calls from libfoo.so to libbar.so and libbaz.so are *not* relocated. d) You take a wild branch out of libfoo.so trying to call bar or baz. The run-time symptom is a segfault in glink.* (usually, trying to load a wild address pointer for the un-relocated function....) To fix, you need to do one of: a) Add '-brtl' flags at appropriate places (you may need to rebuild all the libraries involved). The rtl is "run-time-linker" and basically does relocation and call resolution on libfoo.so after it gets loaded. b) Making the final main program link look like: cc -o mail -lfoo -lbar -lbaz (making sure that *all* the needed shared libs are listed) - this way, libbar.so and libbaz.so will be loaded and relocated at startup along with libfoo.so. Option (b) is usually easiest.
Attachment:
pgpUBTwgxEiEo.pgp
Description: PGP signature