www.digitalmars.com         C & C++   DMDScript  

D.gnu - why no ld.exe in 2.066.1 Windows builds?

reply "Ivan Kazmenko" <gassa mail.ru> writes:
Hi,

On http://gdcproject.org/downloads page, there's a new release 
with 2.066.1 DMD frontend, build date 2015-04-05.

However, in i686-w64-mingw32 and x86_64-w64-mingw32 packages, 
there is no linker (ld.exe). Compiling a hello world program with 
a tdm-gcc[1] linker in the path results in
...
...\ld.exe: this linker was not configured to use sysroots.

So, why is the linker binary not in the package anymore, and 
which linker should I use in its absence?  The ones I have (some 
tdm-gcc, mingw-builds, mingw versions) fail with various "not for 
sysroots" or "symbol not found" errors.

Ivan Kazmenko.
Apr 13 2015
next sibling parent "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 13 April 2015 at 07:38:06 UTC, Ivan Kazmenko wrote:
 with a tdm-gcc[1] linker in the path results in
[1] http://tdm-gcc.tdragon.net/
Apr 13 2015
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Apr 2015 07:38:04 +0000
schrieb "Ivan Kazmenko" <gassa mail.ru>:

 Hi,
 
 On http://gdcproject.org/downloads page, there's a new release 
 with 2.066.1 DMD frontend, build date 2015-04-05.
 
 However, in i686-w64-mingw32 and x86_64-w64-mingw32 packages, 
 there is no linker (ld.exe). Compiling a hello world program with 
 a tdm-gcc[1] linker in the path results in
 ...
 ...\ld.exe: this linker was not configured to use sysroots.
 
 So, why is the linker binary not in the package anymore, and 
 which linker should I use in its absence?  The ones I have (some 
 tdm-gcc, mingw-builds, mingw versions) fail with various "not for 
 sysroots" or "symbol not found" errors.
 
 Ivan Kazmenko.
Seems like something went wrong when updating the build scripts. I'll have a look later today and upload updated releases. BTW: Did you use older windows releases? As windows support is mostly untested I was always wondering if anybody uses windows releases at all ;-)
Apr 13 2015
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 13 April 2015 at 07:50:10 UTC, Johannes Pfau wrote:
 Seems like something went wrong when updating the build 
 scripts. I'll
 have a look later today and upload updated releases.
Thanks, looking forward to it.
 BTW: Did you use older windows releases? As windows support is 
 mostly
 untested I was always wondering if anybody uses windows 
 releases at
 all ;-)
Rather, I toyed with the previous release a bit: simple programs (hello world) compiled and worked, while some of the more complex ones (a few hundred lines) had problems, which is when I switched back to dmd for them and did not investigate further. Right now, I tried the previous (2.065 frontend, gcc 4.9.0 backend) release and reduced one problem to that readf(" ") crashes when it encounters end-of-file: ----- import std.stdio; void main() {readf(" ");} ----- Give it an empty file, and it crashes. Only 32-bit version, 64-bit version works fine. DMD also works fine. After working around that, an 150-ish-line program compiled fine and worked comparably to dmd. Though surprisingly, it performed a bit slower with "-O3 -march=native -frelease". Reading "some stuff, then a whitespace" with readf is useful to put the cursor at the next non-whitespace character. This does not seem to be documented for D (an implementation detail? worth raising a documentation issue?), but works for dmd's readf and for C's scanf (http://www.cplusplus.com/reference/cstdio/scanf/). Ivan Kazmenko.
Apr 13 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Apr 2015 08:44:25 +0000
schrieb "Ivan Kazmenko" <gassa mail.ru>:

 On Monday, 13 April 2015 at 07:50:10 UTC, Johannes Pfau wrote:
 Seems like something went wrong when updating the build 
 scripts. I'll
 have a look later today and upload updated releases.
Thanks, looking forward to it.
Updated builds are on http://gdcproject.org/downloads Thanks for reporting this. Next time I should do some basic tests before uploading, but I didn't have a windows pc ready at that moment.
 BTW: Did you use older windows releases? As windows support is 
 mostly
 untested I was always wondering if anybody uses windows 
 releases at
 all ;-)
Rather, I toyed with the previous release a bit: simple programs (hello world) compiled and worked, while some of the more complex ones (a few hundred lines) had problems, which is when I switched back to dmd for them and did not investigate further. Right now, I tried the previous (2.065 frontend, gcc 4.9.0 backend) release and reduced one problem to that readf(" ") crashes when it encounters end-of-file: ----- import std.stdio; void main() {readf(" ");} ----- Give it an empty file, and it crashes. Only 32-bit version, 64-bit version works fine. DMD also works fine. After working around that, an 150-ish-line program compiled fine and worked comparably to dmd. Though surprisingly, it performed a bit slower with "-O3 -march=native -frelease". Reading "some stuff, then a whitespace" with readf is useful to put the cursor at the next non-whitespace character. This does not seem to be documented for D (an implementation detail? worth raising a documentation issue?), but works for dmd's readf and for C's scanf (http://www.cplusplus.com/reference/cstdio/scanf/). Ivan Kazmenko.
I see. Unfortunately this is kinda expected. I usually only test simple hello-world programs and nobody is really working on MinGW-support. Most D windows users also seem to hope for better llvm/ldc support instead as llvm uses windows compatible debug info and integrates better with msvc. OTOH we'll need (some) MinGW support when DDMD is merged into GDC to compile the windows=>arm cross compilers (those should work just as well as the linux=>arm cross compilers).
Apr 13 2015
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 13 April 2015 at 14:25:57 UTC, Johannes Pfau wrote:
 Am Mon, 13 Apr 2015 08:44:25 +0000
 schrieb "Ivan Kazmenko" <gassa mail.ru>:
 Thanks, looking forward to it.
Updated builds are on http://gdcproject.org/downloads
Hmm. The new 64-bit build worked for me just fine, thanks! On my example program, for the resulting executable, running time and memory consumption are similar to that of dmd64's. However, the 32-bit build locally fails to compile anything: ----- void main(){} ----- Linking errors: ----- c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `_lambda3': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime core/thread.d:1983: undefined reference to `D2rt5tlsgc4initFZPv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `D4core6thread6Thread6__dtorMFZv': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntim /core/thread.d:633: undefined reference to `D2rt5tlsgc7destroyFPvZv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `thread_entryPoint 4': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntim /core/thread.d:193: undefined reference to `D2rt5tlsgc4initFZPv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `thread_attachThis': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime core/thread.d:1903: undefined reference to `D2rt5tlsgc4initFZPv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `thread_attachByAddrB': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime core/thread.d:1968: undefined reference to `D2rt5tlsgc4initFZPv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `D4core6thread15scanAllTypeImplFNbMDFNbE4core6thread8ScanTypePvPvZvPvZv': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime core/thread.d:2666: undefined reference to `D2rt5tlsgc4scanFNbPvMDFNbPvPvZvZv' c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libg hobos2.a(thread.o): In function `thread_processGCMarks': /home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime core/thread.d:2896: undefined reference to `D2rt5tlsgc14processGCMarksFNbPvMDFNbPvZiZv' collect2.exe: error: ld returned 1 exit status ----- Trying to link the libraries manually ("-lgdruntime -lgphobos2") does not change the error. The symbols seem to be present in both libs as far as my understanding goes (tlsgc.o in libgdruntime.a lists __D2rt5tlsgc4initFZPv in my viewer, for example). So, what's wrong? Ivan Kazmenko.
Apr 13 2015
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 13 April 2015 at 15:25:08 UTC, Ivan Kazmenko wrote:
 Trying to link the libraries manually ("-lgdruntime 
 -lgphobos2") does not change the error.  The symbols seem to be 
 present in both libs as far as my understanding goes (tlsgc.o 
 in libgdruntime.a lists __D2rt5tlsgc4initFZPv in my viewer, for 
 example).  So, what's wrong?

 Ivan Kazmenko.
The symbol is listed as _D2rt5tlsgc4initFZPv (one underscore) in 64-bit build and __D2rt5tlsgc4initFZPv int 32-bit build (two underscores). I remember having similar underscore issues when converting COFF <-> OMF libraries for 32-bit dmd. So that may be the explanation. Still, what do I do with that in this particular case? Ivan Kazmenko.
Apr 13 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 13 Apr 2015 15:29:57 +0000
schrieb "Ivan Kazmenko" <gassa mail.ru>:

 On Monday, 13 April 2015 at 15:25:08 UTC, Ivan Kazmenko wrote:
 Trying to link the libraries manually ("-lgdruntime 
 -lgphobos2") does not change the error.  The symbols seem to be 
 present in both libs as far as my understanding goes (tlsgc.o 
 in libgdruntime.a lists __D2rt5tlsgc4initFZPv in my viewer, for 
 example).  So, what's wrong?

 Ivan Kazmenko.
The symbol is listed as _D2rt5tlsgc4initFZPv (one underscore) in 64-bit build and __D2rt5tlsgc4initFZPv int 32-bit build (two underscores). I remember having similar underscore issues when converting COFF <-> OMF libraries for 32-bit dmd. So that may be the explanation. Still, what do I do with that in this particular case? Ivan Kazmenko.
Thanks for the feedback. I can't debug this right now but I'll make a note on the MinGW to-be-fixed list ;-)
Apr 13 2015
parent "Ivan Kazmenko" <gassa mail.ru> writes:
On Monday, 13 April 2015 at 18:33:46 UTC, Johannes Pfau wrote:
 Am Mon, 13 Apr 2015 15:29:57 +0000
 schrieb "Ivan Kazmenko" <gassa mail.ru>:

 On Monday, 13 April 2015 at 15:25:08 UTC, Ivan Kazmenko wrote:
 Trying to link the libraries manually ("-lgdruntime 
 -lgphobos2") does not change the error.  The symbols seem to 
 be present in both libs as far as my understanding goes 
 (tlsgc.o in libgdruntime.a lists __D2rt5tlsgc4initFZPv in my 
 viewer, for example).  So, what's wrong?

 Ivan Kazmenko.
The symbol is listed as _D2rt5tlsgc4initFZPv (one underscore) in 64-bit build and __D2rt5tlsgc4initFZPv int 32-bit build (two underscores). I remember having similar underscore issues when converting COFF <-> OMF libraries for 32-bit dmd. So that may be the explanation. Still, what do I do with that in this particular case? Ivan Kazmenko.
Thanks for the feedback. I can't debug this right now but I'll make a note on the MinGW to-be-fixed list ;-)
I'll also note that druntime and phobos linked just fine in the previous 32-bit Windows release, so it's most likely a regression of the build process.
Apr 13 2015