topic static constructors in dlopen in Operating System - HP-UX

static constructors in dlopen

lara — Thu, 02 Oct 2003 21:59:05 GMT

Hi,

Does anyone know if there is a way to break in each of the static constructors called during dlopen() or destructors during dlclose() of a C++ library.
Currently, I am debugging a problem, where the program segfaults in dlclose() when I close the C++ shared library loaded through dlopen(). I suspect that there is a problem with the static destructors.
I have tried including the cpprt0.s stub suggested in some website and also tried using shl_load() instead of dlopen() and in both the cases it fails while closing.
Does anyone has faced a similar problem? If so can you let me know how to debug it.

Thanks

Re: static constructors in dlopen

ranganath ramachandra — Fri, 03 Oct 2003 01:54:11 GMT

make sure you link with aCC/g++ and not use the linker directly, when linking c++ objects (especially while building shared libraries).

what compiler and linker are you using ? is this a 32-bit or a 64-bit application ?

Re: static constructors in dlopen

lara — Fri, 03 Oct 2003 08:50:47 GMT

Hi,

Yes, I compile with aCC and it's on 32bit platform

Thanks

Re: static constructors in dlopen

ranganath ramachandra — Fri, 03 Oct 2003 22:44:11 GMT

i remember one case of dlclose ending in a core dump, which was solved by the latest linker/loader patch, but i dont have the details.

by the way, you dont just compile with aCC, you also link with it with the "-b" option when building the shared library. cpprt0.s is not required with aCC (i think it may be relevant to either g++ or the obsolete cfront). aCC includes /opt/aCC/lib/shlrt0.o in the link line (and adds an initializer/terminator __shlInit with the +I linker option). however if your initializer is being called, you dont need to bother about all this, just try the latest linker/loader patch and let us know if the problem still exists.

Re: static constructors in dlopen

ranganath ramachandra — Fri, 03 Oct 2003 22:50:07 GMT

correction - cpprt0.o is linked in while building executables and shlrt0.o into shared libraries.

i am not very sure if this helps: "odump -slinit" will list the initializers of the shared library, perhaps you can proceed from here to set breakpoints.