Re: Change to DSO-linking semantics of the compiler

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

 



On Wed, 2010-01-13 at 16:24 +0000, Nick Clifton wrote:
> Hi Guys,
> >> 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
> >>                   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
> 
> 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.

This is the whole point of weak references though.  They go to 0 with no
error if they are not defined in the runtime image.  In other words,
they're explicitly _not_ required; the object with the weak reference is
saying "I know how to behave even if this symbol isn't defined".

For strong references (things ld prints as 'U' symbols), your logic is
correct.  For weak references, it's not.

- ajax

Attachment: signature.asc
Description: This is a digitally signed message part

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