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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
