Shared Library Constructor is not executed - gcc

Question

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

Answer 1

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

Answer 2

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.