Shared Library Constructor is not executed

I have the following problem. I write a shared library

#include <stdio.h>
#include <stdlib.h>

static void __attribute__ ((constructor)) test_init(void);
static void __attribute__ ((destructor))  test_clean(void);

/*  Initialization  */
static void     test_init(void){
        fprintf(stderr,"initialized\n");
        fflush(stderr);
}
/*  CleanUp */
static void test_clean(void){
        fprintf(stderr,"cleaned up\n");
        fflush(stderr);
}

double  test (double x){
    return  2.0*x;
}

And compile it using

gcc -c -fPIC testlib.c -o testlib.o

ld -shared -o libtest.so testlib.o

Then I include it into a test program

#include <stdio.h>
#include <stdlib.h>
extern double   test(double x);
void  开发者_如何学C  main(void){

    printf("%.10e\n",test(10.0));
}

which I compile and start using

gcc testprog.c -o testprog -L. -ltest

LD_LIBRARY_PATH=. ./testprog

Then the output is given by

2.0000000000e+01

which means that the constructor/destructor are not executed. On the other hand, if I compile

ar rvs testlib.a testlib.o

gcc testprog.c testlib.a -o testprog

the output of the program is given by

testprog initialized 2.0000000000e+01 cleaned up

Why are the constructors not executed if the library is linked dynamically?

I use the following versions

GNU ld (GNU Binutils; openSUSE 11.3) 2.20.0.20100122-6 gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)

Thank you in advance for your help!

Edited: 2011-04-13, 11:05

Thank you very much luxifer,

the document helped indirectly! The magic hint was that one should involve the linker through the compiler...

gcc -fPIC testlib.c -shared -Wl,-soname,libtest.so -o libtest.so

works!!!

Gcc's constructor handling is not the same thing as the ELF constructor handling, rather, it sits on top of it. To work, you need to link in the glue code that is provided in gcc's startup files.

The easiest way to do that is to link using gcc:

gcc -shared -o testlib.so testlib.o

This text is meant for reference, but I'm coming over to your office for convenience :)

I'm not an expert on that field but a quick Google search gave me this. Reading just the beginning of the document and if I get it right the problem is this:

Linked statically your program is self-contained at execution time... it has the whole library in it and it's completely loaded into memory when you run it.

Linked dynamically when the library function is called from your program at execution time the linker tries to resolve all unresolved references on functions by looking if it has an implementation in some library. If so it loads this implementation, i.e. just the functions code.

So if I get this right and the dynamic linker just loads portions of libraries, i.e. needed functions, and not the whole library then this would explain why your constructor isn't called when your library is linked dynamically.