Bug 13025 – Tools repository does not build on Ubuntu

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2014-07-02T22:54:00Z
Last change time
2014-08-22T07:17:19Z
Keywords
link-failure
Assigned to
nobody
Creator
briancschott

Comments

Comment #0 by briancschott — 2014-07-02T22:54:54Z
Attempting to build the "tools" repository on Ubuntu 14.4 gives the following error: /usr/bin/ld: ../phobos/generated/linux/release/64/libphobos2.a(sections_linux_517_883.o): undefined reference to symbol '__bss_start' //usr/lib/x86_64-linux-gnu/librtmp.so.0: error adding symbols: DSO missing from command line Adding "-lrtmp" after "-lcurl" fixes the compile. This should not be necessary because I'm sure that none of the tools need this, as "The Real-Time Messaging Protocol (RTMP) is used for streaming multimedia content across a TCP/IP network". My version of ld is "GNU ld (GNU Binutils for Ubuntu) 2.24". I'm not able to reproduce this issue on a Debian system using ld 2.22 or a Gentoo system using ld 2.24.
Comment #1 by code — 2014-07-07T22:17:19Z
CCing Martin.
Comment #2 by code — 2014-07-07T22:22:40Z
Mmh, looks like your linker script doesn't provide __bss_start. The librtmp is probably just a recommendation for a library which provides the missing symbol. Will try it out in a VirtualBox.
Comment #3 by code — 2014-07-08T21:49:19Z
(In reply to Martin Nowak from comment #2) > Mmh, looks like your linker script doesn't provide __bss_start. I had briefly discussed the issue with Brian on IRC before, and the linker script seemed to be fine, defining __bss_start just as usual. Couldn't investigate the issue any closer so far, though.
Comment #4 by code — 2014-07-09T23:41:30Z
If this turns out to be hard to track down or fix, maybe a similar strategy as described for LDC in issue 879 could be employed to avoid the direct __bss_start/_end dependencies in druntime altogether.
Comment #5 by code — 2014-07-11T17:52:38Z
This happens when linking with libcurl, I can add -L--no-as-needed -L-lcurl to any dmd app and it will trigger this issue.
Comment #6 by code — 2014-07-11T17:54:47Z
(In reply to Martin Nowak from comment #5) > This happens when linking with libcurl, I can add -L--no-as-needed -L-lcurl > to any dmd app and it will trigger this issue. This sounds eerily similar to a problem I had with _end way back when: http://stackoverflow.com/questions/13328144/end-symbol-disappears-when-linking-to-libcurl Still unresolved, though.
Comment #7 by code — 2014-07-11T18:00:38Z
(In reply to David Nadlinger from comment #6) > This sounds eerily similar to a problem I had with _end way back when: > http://stackoverflow.com/questions/13328144/end-symbol-disappears-when- > linking-to-libcurl > > Still unresolved, though. Oh, I remember this one, but we actually did resolve it back then. https://github.com/D-Programming-Language/druntime/commit/760aba5256d91327e5b4e79d931bceee4c068cd6 Now the question is, why does linking with libcurl affect the linker provided symbols.
Comment #8 by code — 2014-07-11T18:13:06Z
(In reply to Martin Nowak from comment #7) > Oh, I remember this one, but we actually did resolve it back then. I meant "unresolved" as in "we didn't actually figure out why the symbol disappeared and just worked around it". > Now the question is, why does linking with libcurl affect the linker provided symbols. Yep, this doesn't make a lot of sense. I guess we could always use the workaround I described in issue 878 for --gc-sections to avoid these problems and get the release out. If the DMD backend can emit weak symbols already, it should be rather painless.
Comment #9 by code — 2014-07-11T18:59:07Z
OK, I could reproduce the issue with a few C files. It seems to be caused by a diagnostic bug in the linker. For some reason (optimized linker scipt, hidden visibility) libcurl.so does not carry _end and __bss_start, but one of it's dependencies does, librtmp.so. When the linker sees that the undefined symbols __bss_start/_end are dynamically exported by librtmp it throws an error, telling you that you're not linking against librtmp even though you rely on one of it's symbols. You can suppress this warning with -unresolved-symbols=ignore-in-shared-libs and everything will work as expected. We cannot use the PROVIDE(edata = .) and PROVIDE(end = .) symbols, because then libphobos.so would not point to the correct bss segment of the executable. I think it should be possible to find the .bss segment of the executable in sections_linux though.
Comment #10 by yazan.dabain — 2014-07-11T20:30:48Z
Comment #11 by code — 2014-07-11T21:17:58Z
*** Issue 13097 has been marked as a duplicate of this issue. ***
Comment #12 by code — 2014-07-12T19:55:53Z
I think the following should work around the linker bug. Will try it when I'm back home. Mark __bss_start and _end as weak references, the linker is going to define them anyhow, so no reference in main is necessary.
Comment #13 by github-bugzilla — 2014-07-14T00:38:34Z
Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/94c35b9116fe43157738988ffba5aa2d88e0ec2a fix Issue 13025 - Tools repository does not build on Ubuntu - reference __bss_start and _end using weak symbols to workaround a diagnostic linker bug https://github.com/D-Programming-Language/druntime/commit/7474e953a913125a43daad8d2c11464e795d6b6c Merge pull request #889 from MartinNowak/fix13025 fix Issue 13025 - Tools repository does not build on Ubuntu
Comment #14 by github-bugzilla — 2014-07-15T10:26:20Z
Commit pushed to 2.066 at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/7502b0dc1e03743e725dbbb81e7e187e6f6b34fe Merge pull request #889 from MartinNowak/fix13025 fix Issue 13025 - Tools repository does not build on Ubuntu
Comment #15 by github-bugzilla — 2014-08-22T07:17:19Z