On 01/11/2010 10:45 AM, Charley Wang wrote:
> Hi Fedora Developers,
>
> This is a quick announcement of the proposed change to DSO linking
> (https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking).
>
> The change will force explicit declaration of links rather than implicitly
> detecting links. More detailed info is here:
>
> https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>
> A rebuild was conducted, and a preliminary (unsorted) list of packages
> that have implicit linkage errors can be found here:
>
> https://fedoraproject.org/wiki/DSOLinkBugs
>
> Please note that many of the packages may be failing because of a few
> DSO's. Further exploration is needed to evaluate this possibility so
> we can apply one patch to the source of the problem instead of dozens of
> superfluous patches. We also need (and would appreciate help with) the
> linking of failed build logs to their package owners.
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. Consider this minimal example:
$ cat string.cxx
#include <string>
int main()
{
return std::string("foo").length() != 3;
}
$ g++ -c string.cxx
$ nm -C string.o
U _Unwind_Resume
U std::string::length() const
U std::allocator<char>::allocator()
U std::allocator<char>::~allocator()
U std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(char const*, std::allocator<char>
const&)
U std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string()
0000000000000008 r __gthread_active_p()::__gthread_active_ptr
U __gxx_personality_v0
0000000000000000 T main
w pthread_cancel
$ g++ -o string string.o
This is fine, becauses __gthread_active_p is just using the fact that
the weak pthread_cancel symbol becomes 0 if libpthread isn't linked.
But if one of your dependent libraries uses pthreads, suddenly the main
executable gets the normal pthread_cancel symbol too, and the new linker
serves up death:
$ 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
/lib64/libpthread.so.0: could not read symbols: Invalid operation
*** /usr/bin/ld: ld behavior mismatch! ***
*** /usr/bin/ld.bfd succeeeded ***
*** /usr/bin/ld.bfd --no-add-needed exits 1 ***
*** arguments: --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -o string
/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.2/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../.. string.o -ldb -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-redhat-linux/4.4.2/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crtn.o
collect2: ld returned 1 exit status
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.
75 of the failed packages have an undefined reference to pthread_cancel,
probably for the same reason as above.
Josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
