Re: Change to DSO-linking semantics of the compiler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux