Change to DSO-linking semantics of the compiler

[Jakub Jelinek]

On Wed, Jan 13, 2010 at 12:10:06PM -0500, Adam Jackson wrote:
> On Wed, 2010-01-13 at 16:24 +0000, Nick Clifton wrote:
> > >> $ g++ -o string string.o -ldb
> > >> /usr/bin/ld.bfd: string.11980.test: undefined reference to symbol
> > >> 'pthread_cancel@@GLIBC_2.2.5'
> > >> /usr/bin/ld.bfd: note: 'pthread_cancel@@GLIBC_2.2.5' is defined in DSO
> > >> /lib64/libpthread.so.0 so try adding it to the linker command line
> > 
> > But, you have added an explicit dependency upon libdb to your executable 
> > by mentioning -ldb on the gcc command line.  Therefore libdb will be 
> > loaded at execution start-up.  But libdb has a dependency upon 
> > libpthread, so that library will also be loaded at execution start-up. 
> > Hence when you run 'string' the pthread_cancel symbol will be resolved 
> > and so 'string' really does now have a resolved reference to 
> > pthread_cancel.  Hence the linker is correct in complaining that you 
> > have a reference to a symbol that is defined in a library which have not 
> > included on the linker command line.
> > 
> > At least that is how I see it at the moment.
> 
> This is the whole point of weak references though.  They go to 0 with no
> error if they are not defined in the runtime image.  In other words,
> they're explicitly _not_ required; the object with the weak reference is
> saying "I know how to behave even if this symbol isn't defined".

Yeah, string will work well even when -ldb stops being linked against
-lpthread, therefore forcing it to require -lpthread is a bad idea.
And it will even pessimize it.  The whole point why gthr.h uses these weak
references is that compiled code is thread safe when -lpthread is loaded,
but does not require it and is actually quite cheaper if -lpthread is not
loaded.

	Jakub