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.
(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
*** 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