Remaining Travis merge-2.064 failure
David Nadlinger via digitalmars-d-ldc
digitalmars-d-ldc at puremagic.com
Tue May 20 02:51:01 PDT 2014
On Mon, May 19, 2014 at 7:36 AM, Kai Nacke via digitalmars-d-ldc
<digitalmars-d-ldc at puremagic.com> wrote:
> I think this is a problem with the multilib setup. This Travis build passes:
> https://travis-ci.org/ldc-developers/ldc/builds/25474830 - the only
> difference is that the 32bit libraries are not build (and some applications
> are not installed, e.g. gcc-multilib).
There is still be the possibility that this is a bug in LDC. If it's a
case of template symbols not being emitted correctly, then the order
in which the other object files in libphobos.a are tried might differ
between different toolchain versions, and we might just get unlucky to
hit curl.o (std.net) in the multilib case.
If you have a setup where you can actually reproduce this, it might be
worth having a short look at what actually causes curl.o to be pulled
in. Maybe GNU ld has an option similar to the OS X one to do this, but
if you can't find it like me, you could adapt that hacky script I sent
you once to track down which unresolved symbol causes the issue.
I agree that it is not worth postponing the release due to this,
though, if we don't have concrete evidence that this also affects user
More information about the digitalmars-d-ldc