Segmentation fault in glink.fflush at 0xd1fda988 ($t1)
Oh joy. ;)
that was pretty much my reaction :)
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.
So, by default, AIX is rather like Windows or OpenVMS in that the
library an executable loads cannot reach-out and call a routines from
the executable itself :(
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.
Am I correct in assuming that also means main?
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.
I think I need to take option a - in my case libfoo is being dynamically
loaded vi g_module_open.
I would have thought that libtool would have included that option for
AIX when it was told to -export-dynamic?
Anyway, I'll try adding the -brtl and see what happens. Thanks,
rick jones
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
