D.gnu - why no ld.exe in 2.066.1 Windows builds?
- Ivan Kazmenko (13/13) Apr 13 2015 Hi,
- Ivan Kazmenko (2/3) Apr 13 2015 [1] http://tdm-gcc.tdragon.net/
- Johannes Pfau (7/24) Apr 13 2015 Seems like something went wrong when updating the build scripts. I'll
- Ivan Kazmenko (24/32) Apr 13 2015 Rather, I toyed with the previous release a bit: simple programs
- Johannes Pfau (13/52) Apr 13 2015 Updated builds are on http://gdcproject.org/downloads
- Ivan Kazmenko (49/53) Apr 13 2015 Hmm.
- Ivan Kazmenko (8/14) Apr 13 2015 The symbol is listed as _D2rt5tlsgc4initFZPv (one underscore) in
- Johannes Pfau (4/21) Apr 13 2015 Thanks for the feedback. I can't debug this right now but I'll make a
- Ivan Kazmenko (4/25) Apr 13 2015 I'll also note that druntime and phobos linked just fine in the
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
"Ivan Kazmenko" <gassa mail.ru> 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
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
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
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: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.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.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).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
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>: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.Thanks, looking forward to it.Updated builds are on http://gdcproject.org/downloads
Apr 13 2015
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
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:Thanks for the feedback. I can't debug this right now but I'll make a note on the MinGW to-be-fixed list ;-)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
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>: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.On Monday, 13 April 2015 at 15:25:08 UTC, Ivan Kazmenko wrote:Thanks for the feedback. I can't debug this right now but I'll make a note on the MinGW to-be-fixed list ;-)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