Comment # 10 on bug 202 from Johannes Pfau

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.