This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: shared objects .init section not executed !?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]