This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: shared objects .init section not executed !?
- To: Torsten dot Duwe at caldera dot de
- Subject: Re: shared objects .init section not executed !?
- From: Andreas Jaeger <aj at suse dot de>
- Date: 09 Aug 2000 08:21:06 +0200
- Cc: libc-alpha at sourceware dot cygnus dot com, duwe at caldera dot de
- References: <200008081152.NAA00338@ns.lst.de>
>>>>> Torsten Duwe writes:
> Hi everyone,
> I've stumbled across this yesterday, and after a little examination it seems
> that libdl / ld.so is the culprit. Obviously "ld -shared" bravely collects
You shouldn't use ld -shared. Please try gcc -shared.
> all the .ctors of library objects, wraps them, constructs a .init section to
> call them all, only for ld.so to ignore the whole work.
> Here is the test case, with C++ constructors used for the demonstration: the
> main program links to a library containing a static/global object, and calls
> a library function to read its state:
Which glibc version are you using?
> #include <ostream.h>
> extern int libfunc();
> int
> main (int argc, char ** argv)
> {
> cout << libfunc() << "\n";
> return 0;
> }
> Here's an extract of the library file:
> class cl {...};
> cl cl_obj;
> int
> libfunc()
> {
> return cl_obj.getval();
> }
> where getval depends on cl_obj's initializer having been called or
> not. Linking "statically" with the library object shows the constructor
> properly has been called, while making it an .so file exposes the bug.
> Have I overlooked something fundamentally, is this intentional for some
> obscure reason or is it simply a yet undiscovered bug ?
> Torsten
> whole test case for your convenience:
> --[[application/octet-stream; type=tar+gzip
> Content-Disposition: attachment; filename="solib-inittest.tar.gz"][base64]]
That's no proper MIME-attachment. Please resend it.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj