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.

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/

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 ;-)

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.

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).

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/libgphobos2.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/libgphobos2.a(thread.o): In function `D4core6thread6Thread6__dtorMFZv':
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/core/thread.d:633: undefined reference to `D2rt5tlsgc7destroyFPvZv'
c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libgphobos2.a(thread.o): In function `thread_entryPoint@4':
/home/build/tmp/build/.build/src/gcc-4.9.2/libphobos/libdruntime/core/thread.d:193: undefined reference to `D2rt5tlsgc4initFZPv'
c:/software/gdc32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../lib/libgphobos2.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/libgphobos2.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/libgphobos2.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/libgphobos2.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.

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.

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 ;-)

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.