http://bugzilla.gdcproject.org/show_bug.cgi?id=202

--- Comment #9 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
This gets weirder.
The following program shows the error (undefined references to curl):

int main()
{
  import std.stdio;
  import std.conv;

  stdin.byLine();
  char[] s;

  to!int(s);
  parse!int(s);


  return 0;
}

But, swapping the calls to 'to' and 'parse' makes it link just fine.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=202

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau@gmail.com

--- Comment #10 from Johannes Pfau <johannespfau@gmail.com> ---
I think I've found the problem:

fail.d
------------------------------------------
int main()
{
  import std.stdio;
  import std.conv;

  stdin.byLine();
  char[] s;

  to!int(s);
  parse!int(s);


  return 0;
}
------------------------------------------

ok.d
------------------------------------------
int main()
{
  import std.stdio;
  import std.conv;

  stdin.byLine();
  char[] s;

  parse!int(s);
  to!int(s);


  return 0;
}
------------------------------------------

gdc fail.d // linker error
gdc ok.d  // works

gdc fail.d -c -o fail.o
gdc fail.o // linker error
gdc ok.d -c -o ok.o
gdc ok.o // works

nm fail.o > fail.sym
nm ok.o > ok.sym

diff -u fail.sym ok.sym
-                 U _D3std5array15__T8popFrontTaZ8popFrontFNaNbNiNeKAaZv
+0000000000000000 W _D3std5array15__T8popFrontTaZ8popFrontFNaNbNiNeKAaZv


nm /usr/lib64/libgphobos2.a > sym.txt _D3std5array15__T8popFrontTaZ8popFrontFNaNbNiNeKAaZv is in curl.o



So what happens is this: In some cases template instances are not emitted as
weak symbols, probably as the compiler correctly infers these templates are
already instantiated in some of the imported modules. The symbol is actually
defined in the curl.o object file though, so it will be linked into the
executable.
I'm not sure whether this actually is a DMD template bug where the compiler
should emit the template (as there is no
_D3std5array15__T8popFrontTaZ8popFrontFNaNbNiNeKAaZv in any other module). OTOH
maybe _D3std5array15__T8popFrontTaZ8popFrontFNaNbNiNeKAaZv should be emitted in
other modules as well (this should be a very common function), but packaging
into a static library merged the weak symbols and unfortunately chose the one
from curl.o?


As a workaround, -femit-templates should work.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=202

--- Comment #11 from Iain Buclaw <ibuclaw@gdcproject.org> ---
That probably explains why I can't see it in my 2.067 branch.  I have redone a little bit our template emission strategy.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=202

--- Comment #12 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
Thanks for the info. In the meantime, I'm using the -femit-templates option as workaround.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=202

--- Comment #13 from Iain Buclaw <ibuclaw@gdcproject.org> ---
It looks like it is a front-end bug.  But GDC does no better by listening to TemplateInstance::needsCodegen()

Why it returns true in the working and false in the broken case, I have no idea.  Ask Kenji, but I have reasons to believe this was fixed in 2.067.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=202

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #14 from Iain Buclaw <ibuclaw@gdcproject.org> ---
2.067 has been merged in, so this is no longer reproducible.

I think that the "proper" fix is for dynamic loading of curl to be enabled.

-- 
You are receiving this mail because:
You are watching all bug changes.

https://bugzilla.gdcproject.org/show_bug.cgi?id=202

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #15 from Johannes Pfau <johannespfau@gmail.com> ---
std.net.curl now loads curl dynamically.

etc.c.curl still directly references external functions. A simple nm on the object file shows no external reference functions though, I guess this is as etc.c.curl only declares these functions yet never calls them.

-- 
You are receiving this mail because:
You are watching all bug changes.