Change to DSO-linking semantics of the compiler

[John Reiser]

>> SystemTap is failing on pthread_cancel, which is odd since we have no
>> mention of pthread in our own sources.  It seems to be pulled in by some
>> headers in the STL.

>> $ nm -C string.o
>>                   w pthread_cancel

>> So it seems that now I have to know what my dependent libraries are
>> linking to, which I thought was exactly what we were trying to eliminate
>> with these new linking semantics.

> The weak undefined reference does need to be associated with the real
> definition to some degree, in that it uses that symbol version assocation.

No, a weak reference that is undefined (within the module that contains the
reference) must not be associated with any symbol version at all.  An undefined
weak reference says "I am satisfied with whatever any other module supplies,
else 0 (NULL)."  This willingness to tolerate uncertainty, and to delay
resolution, must extend all the way to runtime.

As a matter of historical interest, then static linking (/usr/bin/ld)
might record a symbol version for an undefined weak reference.  The history
is, "this is how it could have been resolved at static linking."  But any
recorded symbol version for an undefined weak reference must be ignored by
dynamic linking, precisely to enable the independent interchanging of other
modules (DSO) at runtime.

> But clearly the mere presence of a weak reference should never trigger any
> kind of "undefined reference" error.
>
>> 75 of the failed packages have an undefined reference to pthread_cancel,
>> probably for the same reason as above.
>
> We'll fix the toolchain and/or libstdc++ as needed for this.
> Those packages should not need a change just because of this issue.

Right.  binutils and glibc/rtld have been poorly prepared for this change.
The mass rebuild and discussion of the impact of weak undefined references
should have been six weeks ago at the start of development for Fedora 13.
If not fixed before January 20, one week before alpha, then the change
should be removed from Fedora 13.

--