Re: dlopen() does not call static constructors on HP-UX

[Harri Pasanen <harri at nerim dot net>]

On Saturday 07 December 2002 06:09, John David Anglin wrote:
> > > Looks like on HP-UX 11.00,  using g++ 3.2, when I link against a
> > > shared library containing static objects, their constructors are
> > > called.  But if I do dlopen(), or shl_load() for the shared
> > > library, the static objects are not initialized.
> >
> > I have an impression that DT_INIT_ARRAY/DT_FINI_ARRAY may work with
> > HP-UX if ELF is used.
>
> The 32-bit port uses collect to collect constructors and these are
> all run just after main is entered.  There is no way this will work
> with a dlopened library.  As H. J. noted, you can use +init/+fini
> switches, I think with both the 32 and 64-bit HP linkers.  On the
> 32-bit port, you would have to manually build the
> constructor/destructor lists along the lines as is done by collect.
>

I've currently been only experimenting with 32 bit port, apparently the 
64 bit port seems to be broken, both 3.2 and the CVS version.

Looking at what is happening when shared library is linked with 
-Wl,+debug, I noticed that each shared lib appears to have just one 
function that calls the constructors.   That function appears to be 
smart enough, so that if it is called more than once, it will still 
only construct the objects once.

So if I have a C++ built shared library called foo.sl, the function 
resposible called the constructors is called _GLOBAL__FI_foo_sl.
By passing -Wl,+I -Wl,_GLOBAL__FI_foo_sl to the linker when linking the 
shared lib, the loader will call _GLOBAL__FI_foo_sl and all the 
constructors are called.  This works also when dlopen/shl_load is used, 
and appears to do no harm if it is linked with directly.

I have not bothered about calling the destructors, as I'm not unloading 
any libs.

It is possible to make the above process fully automatic, but it 
requires first building the shared lib, looking if the _GLOBAL__FI_* 
symbol is present and then rebuilding it.

So all this is done without any modifications to gcc itself.   Can you 
see any pitfalls with my approach?   I'll let you know if I run into 
any problems.

-Harri