Remaining Travis merge-2.064 failure

[David Nadlinger via digitalmars-d-ldc]

On 9 Jun 2014, at 10:44, Christian Kamm via digitalmars-d-ldc wrote:
> I think the comment in there (functions.cpp:922) is wrong. The 
> frontend
> seems to try hard to make sure instantiatingModule is a non-root 
> module
> if possible. That should mean LDC is not emitting templates that have 
> a
> non-root module instantiating them somewhere.

This logic was adapted from what I gathered from discussions when 2.064 
(I think) came out. If you look at FuncDeclaration::toObjFile in DMD 
2.064.2, you'll see that it uses the same logic to determine whether to 
emit a certain symbol.

In more recent versions, Kenji has moved the check into the frontend at 
our (GDC/LDC) request, but it is still fundamentally the same 
(FuncDeclaration::needsCodegen, 
https://github.com/D-Programming-Language/dmd/pull/3107).

> The idea probably is that you shouldn't need to emit functions again 
> if
> they were already emitted into a library you import and link. (if 
> that's
> desired, the correct fix is probably to require -lcurl when linking
> phobos...)

The idea is instead that functions that are already part of an *object 
file* you need to link anyway should not be emitted again. This is a 
sound design, as long as you only omit template instances that you know 
are already required by somebody else in your dependency graph (ignoring 
cycles for the moment).

Now, obviously std.net.curl isn't in the import graph of std.stdio. What 
seems to happen here is that std.net.curl only contains the symbol by 
accident, even though we thought it was going to be provided by somebody 
else. And as we don't build with symbol-per-section and --gc-sections 
yet, this of course causes us to also pull in the libcurl dependencies. 
Thinking about this a bit, it seems very plausible that the compiler 
actually works as intended here.

This suggests that a possible fix would be to split off everything that 
depends on curl into a separate static library, as this would guarantee 
that the linker looks up the object files from the non-curl modules 
first (but then, of course, we'd either have to specify libphobos-ldc 
twice, or use the GNU ld grouping options, to get std.net.curl to link 
with its Phobos dependencies).

Best,
David