Change to DSO-linking semantics of the compiler

[Roland McGrath]

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

That would all be correct if it were not a weak reference.  But it is.

I doubt that gold behaves this way.  Does it?

Regardless of what's correct, I think we agree that BFD-ld --no-add-needed
and gold should behave consistently.  Probably we should take this to the
binutils list to resolve what all the linker experts think is right.

If your logic above holds, then all "if (&weak_symbol == 0)" tests become
useless.  You've redefined the semantics of a weak reference to have all
the requirements of a strong reference except when nobody anywhere defines
the symbol.

I'm not all clear yet on jreiser's points about the symbol version binding.
But let's leave that as a separate issue to resolve with the ld and rtld
experts on symbol versioning.


Thanks,
Roland