February 16, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
February 16, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
February 16, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
February 17, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
March 03, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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. |
May 22, 2016 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
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. |
June 29, 2017 [Bug 202] Undefined reference to libcurl functions with small program (not explicitly using network). | ||||
---|---|---|---|---|
| ||||
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. |
Copyright © 1999-2021 by the D Language Foundation