Re: how serious are these compiler warnings?

[Rick Jones <rick jones2 hp com>]

> > 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