www.digitalmars.com         C & C++   DMDScript  

D.gnu - Compiling GDC-MinGW

reply Benjamin Thaut <code benjamin-thaut.de> writes:
So I'm trying to build GDC-MinGW from source and I'm running into an 
issue. The configure script of the ppl-tdm64 gets stuck after printing
"checking if the compiler has the remainder bug..." the conf exectuable 
executes with 13% cpu usage forever.

What I did to compile GDC-Mingw:

Install tdm-gcc 4.7.1 as c/c++ compiler (I also tried with 4.6.1 same issue)
Installing msys
Installing wget and unzip for msys
Cloning the mingw branch of github.com/venix1/GDC
Running "build-tdm-gcc.sh" from within msys.

Any help would be apprechiated.

Kind Regards
Benjamin Thaut
Mar 03 2013
parent reply "jerro" <a a.com> writes:
On Sunday, 3 March 2013 at 21:47:16 UTC, Benjamin Thaut wrote:
 So I'm trying to build GDC-MinGW from source and I'm running 
 into an issue. The configure script of the ppl-tdm64 gets stuck 
 after printing
 "checking if the compiler has the remainder bug..." the conf 
 exectuable executes with 13% cpu usage forever.

I remember running into this once. IIRC, you need to just kill conftest.exe or whatever the program that hangs is called. Also, this seems to support that: https://github.com/joshuanapoli/arm-none-eabi-gcc/blob/master/build-arm-none-ebai-gcc#L75
Mar 03 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 03.03.2013 23:25, schrieb jerro:
 On Sunday, 3 March 2013 at 21:47:16 UTC, Benjamin Thaut wrote:
 So I'm trying to build GDC-MinGW from source and I'm running into an
 issue. The configure script of the ppl-tdm64 gets stuck after printing
 "checking if the compiler has the remainder bug..." the conf
 exectuable executes with 13% cpu usage forever.

I remember running into this once. IIRC, you need to just kill conftest.exe or whatever the program that hangs is called. Also, this seems to support that: https://github.com/joshuanapoli/arm-none-eabi-gcc/blob/master/build-arm-none-ebai-gcc#L75

Thanks, that works. Kind Regards Benjamin Thaut
Mar 04 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Ok next problem,

when building ppl I get the error message "'itimerval' does not name a 
type". Is this a known issue too?

Kind Regards
Benjamin Thaut
Mar 04 2013
parent reply Daniel Green <venix1 gmail.com> writes:
On 3/4/2013 12:49 PM, Benjamin Thaut wrote:
 when building ppl I get the error message "'itimerval' does not name a
 type". Is this a known issue too?

I don't believe I've ran into that specific problem. What more can you tell me about the build environment/error generated?
Mar 05 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.03.2013 10:54, schrieb Daniel Green:
 On 3/4/2013 12:49 PM, Benjamin Thaut wrote:
 when building ppl I get the error message "'itimerval' does not name a
 type". Is this a known issue too?

I don't believe I've ran into that specific problem. What more can you tell me about the build environment/error generated?

Well I tried building it using tdm-gcc 4.7.1 Grep-ing the whole tdm-gcc directory revealed that itimerval is indeed not defined anywhere in the headers. I also used the latest version of msys and compiled on Windows 7 x64. Later today I will try compiling with the latest version of vanilla mingw. I also noted that one part of the tlsfix.patch gets rejected, so I applied it manually. It looks like the patch should perfectly work, but for some reason its rejected. But you can easily miss that as the output of the build script runs by that quickly. -- Kind Regards Benjamin Thaut
Mar 05 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Ok I just tested it with vanialla mingw, same problem itimerval is not 
defined in any of the mingw headers and thus compilation of ppl will fail.

Kind Regards
Benjamin Thaut
Mar 05 2013
parent reply Daniel Green <venix1 gmail.com> writes:
On 3/5/2013 2:02 PM, Benjamin Thaut wrote:
 Ok I just tested it with vanialla mingw, same problem itimerval is not
 defined in any of the mingw headers and thus compilation of ppl will fail.

It looks like a configuration issue when compiling PPL. itimerval looks POSIX only. Which version did you compile? I had no issue compiling it with PPL .11 and the following configure. $ /crossdev/src/ppl-0.11/configure --prefix=/crossdev/support-stage-tdm64/ppl/64 --build=x86_64-w64-mingw32 --disable-static --enable-shared CFLAGS=-O2 -I/crossdev/support-stage-tdm64/gmp/64/include CXXFLAGS=-DNULL=0 -O2 -I/crossdev/support-stage-tdm64/gmp/64/include LDFLAGS=-s -L/crossdev/support-stage-tdm64/gmp/64/lib The important option there is likely the --build=x6_64-w64-mingw32
Mar 06 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.03.2013 18:00, schrieb Daniel Green:
 On 3/5/2013 2:02 PM, Benjamin Thaut wrote:
 Ok I just tested it with vanialla mingw, same problem itimerval is not
 defined in any of the mingw headers and thus compilation of ppl will
 fail.

It looks like a configuration issue when compiling PPL. itimerval looks POSIX only. Which version did you compile? I had no issue compiling it with PPL .11 and the following configure. $ /crossdev/src/ppl-0.11/configure --prefix=/crossdev/support-stage-tdm64/ppl/64 --build=x86_64-w64-mingw32 --disable-static --enable-shared CFLAGS=-O2 -I/crossdev/support-stage-tdm64/gmp/64/include CXXFLAGS=-DNULL=0 -O2 -I/crossdev/support-stage-tdm64/gmp/64/include LDFLAGS=-s -L/crossdev/support-stage-tdm64/gmp/64/lib The important option there is likely the --build=x6_64-w64-mingw32

Well I did compile 0.11. I just used your build-tdm-gcc.sh which downloads and compiles 0.11. I fixed this issue by opening crossdev\src\ppl-0.11\Watchdog\src\pwl.hh.dist and setting PWL_HAVE_DECL_SETITIMER to 0. But after that the problems just started. The next thing was that msys told me there is a unkown command " " (really just a space) in update-mingw.sh line 37. I could also fix that by removing all the "&& \" from update-mingw.sh line 36 to 43. Then the next problem appeard, configure of gdc would tell me that the d language depends on the c++ language. Your build-tdm-gcc.sh script does not download the sources for the g++ so I did it manually (I made sure the grab the sources for g++ 4.6.1 from the tdm download page). I extracted the downloaded sources to /crossdev/gdc64/v2 Then it finally started compiling, just to give me the next issues. When it tries to compile \crossdev\gdc64\v2\build\gcc\options.c the compiler throws tons of erros because of what appear to be multiline strings (the newlines are not escaped with '\'). And that is where I'm currently stuck. Here is what I did to setup everything: git clone git://github.com/venix1/GDC.git to C:\Users\...\Documents\d-projects\GDC git checkout mingw Install mingw-get to C:\MinGW downloaded from http://sourceforge.net/projects/mingw/files/ Installed msys to C:\MinGW\msys from http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/ Followed the instructions here to make the mingw-get-gui work: http://sourceforge.net/p/mingw/news/2013/02/graphical-installer-interface-pre-release-snapshots-available/ Installed the following packages with the mingw-get-gui: mingw32-gcc mingw32-g++ msys-rsync msys-patch msys-wget msys-unzip In a msys shell: copy /etc/fstab.sample to /etc/fstab and add a /crossdev mapping to F:/crossdev Run the build-tdm-gcc.sh and observe all the errors. I will keep you updated as soon as I make any progress. Kind Regards Benjamin Thaut
Mar 06 2013
parent reply Daniel Green <venix1 gmail.com> writes:
On 3/6/2013 12:45 PM, Benjamin Thaut wrote:
 Well I did compile 0.11. I just used your build-tdm-gcc.sh which
 downloads and compiles 0.11. I fixed this issue by opening
 crossdev\src\ppl-0.11\Watchdog\src\pwl.hh.dist and setting
 PWL_HAVE_DECL_SETITIMER to 0.

F:\crossdev . I've never done a compile from a separate drive. Two things, you made that directory before starting the build? It won't be made automatically. Can you supply the config.log of the failed build?
 But after that the problems just started. The next thing was that msys
 told me there is a unkown command " " (really just a space) in
 update-mingw.sh line 37. I could also fix that by removing all the "&&
 \" from update-mingw.sh line 36 to 43.

 Then the next problem appeard, configure of gdc would tell me that the d
 language depends on the c++ language. Your build-tdm-gcc.sh script does
 not download the sources for the g++ so I did it manually (I made sure
 the grab the sources for g++ 4.6.1 from the tdm download page). I
 extracted the downloaded sources to /crossdev/gdc64/v2

I've just finished the dependencies here, now it's on to GDC itself. I'll push the update once I look into the TLS issue you mentioned. "I also noted that one part of the tlsfix.patch gets rejected" One question though, which patch exactly was it? There are 5 different TLS patches. tls-binutils-2.21.53-20110731.patch tls-mingw64-runtime.patch mingw-tls-gcc-4.6.x.patch tls-mingwrt-3.20.patch tlssup.c.patch
Mar 06 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 06.03.2013 21:42, schrieb Daniel Green:
 On 3/6/2013 12:45 PM, Benjamin Thaut wrote:
 Well I did compile 0.11. I just used your build-tdm-gcc.sh which
 downloads and compiles 0.11. I fixed this issue by opening
 crossdev\src\ppl-0.11\Watchdog\src\pwl.hh.dist and setting
 PWL_HAVE_DECL_SETITIMER to 0.

F:\crossdev . I've never done a compile from a separate drive. Two things, you made that directory before starting the build? It won't be made automatically. Can you supply the config.log of the failed build?
 But after that the problems just started. The next thing was that msys
 told me there is a unkown command " " (really just a space) in
 update-mingw.sh line 37. I could also fix that by removing all the "&&
 \" from update-mingw.sh line 36 to 43.

 Then the next problem appeard, configure of gdc would tell me that the d
 language depends on the c++ language. Your build-tdm-gcc.sh script does
 not download the sources for the g++ so I did it manually (I made sure
 the grab the sources for g++ 4.6.1 from the tdm download page). I
 extracted the downloaded sources to /crossdev/gdc64/v2

I've just finished the dependencies here, now it's on to GDC itself. I'll push the update once I look into the TLS issue you mentioned. "I also noted that one part of the tlsfix.patch gets rejected" One question though, which patch exactly was it? There are 5 different TLS patches. tls-binutils-2.21.53-20110731.patch tls-mingw64-runtime.patch mingw-tls-gcc-4.6.x.patch tls-mingwrt-3.20.patch tlssup.c.patch

Its the tls-mingwrt.3.20.patch it rejects the 64 bit part: -_CRTALLOC(".tls") const IMAGE_TLS_DIRECTORY64 _tls_used = { - (ULONGLONG) &_tls_start+1, (ULONGLONG) &_tls_end, (ULONGLONG) &_tls_index, +_CRTALLOC(".rdata$TLS") const IMAGE_TLS_DIRECTORY64 _tls_used = { + (ULONGLONG) &_tls_start, (ULONGLONG) &_tls_end, (ULONGLONG) &_tls_index, Why sould it matter that crossdev is on F:\ ? from within msys it should behave exactly the same. Also do you have some idea about the multiline strings in options.c? Google tells me that multiline strings got deprecated starting with gcc 4.0.0 (current mingw vanilla is gcc 4.7.2) Kind Regards Benjamin Thaut
Mar 06 2013
parent reply Daniel Green <venix1 gmail.com> writes:
The crossdev directory is important because GCC is being called natively 
and it allows paths to match up.

Otherwise /crossdev becomes /mingw/msys/1.0/crossdev which causes all 
sorts of mayhem.  That said, as long as you are building on F:\ it there 
shouldn't be an issue.

On 3/6/2013 2:55 PM, Benjamin Thaut wrote:
 Also do you have some idea about the multiline strings in options.c?
 Google tells me that multiline strings got deprecated starting with gcc
 4.0.0 (current mingw vanilla is gcc 4.7.2)

I think this and the issue with tls-mingwrt.3.20.patch may be related. It applies cleanly here. How is your git version designed to handle line endings? A patch that different between Unix/Dos can fail to apply even though they are identical. I also didn't run into an issue with options.c . May also, be a patch getting misapplied. Unless changed during installation msys-git will checkout all files as Dos line endings.
Mar 07 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.03.2013 17:42, schrieb Daniel Green:
 The crossdev directory is important because GCC is being called natively
 and it allows paths to match up.

 Otherwise /crossdev becomes /mingw/msys/1.0/crossdev which causes all
 sorts of mayhem.  That said, as long as you are building on F:\ it there
 shouldn't be an issue.

 On 3/6/2013 2:55 PM, Benjamin Thaut wrote:
 Also do you have some idea about the multiline strings in options.c?
 Google tells me that multiline strings got deprecated starting with gcc
 4.0.0 (current mingw vanilla is gcc 4.7.2)

I think this and the issue with tls-mingwrt.3.20.patch may be related. It applies cleanly here. How is your git version designed to handle line endings? A patch that different between Unix/Dos can fail to apply even though they are identical. I also didn't run into an issue with options.c . May also, be a patch getting misapplied. Unless changed during installation msys-git will checkout all files as Dos line endings.

So are the files supposed to have DOs-Style line endings (CRLF) or Linux-Style line endinngs (LF) ? You might want to include a .gitattributes file which forces the line ending onto the correct format. I tried the tls-mingwrt.3.20.patch both with LF and CRLF line endings and in both cases it fails to apply. It also seems that your script does not download sqlite-amalgamation-3071100.zip Kind Regards Benjamin Thaut
Mar 07 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Also its the tlssup.c.patch that failes. I told you wrong the last time. 
LF / CRLF does not make any difference though

Are you using patch of mingw-msys? Or are you running the script from 
within the git-msys shell?

Kind Regards
Benjamin Thaut
Mar 07 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
So I completely reinstalled MinGW. Now the patch correctly applies, but 
now make will freeze in random places of the build process. It will just 
hang there with 13% cpu usage and will never continue.

Kind Regards
Benjamin Thaut
Mar 08 2013
parent reply Daniel Green <venix1 gmail.com> writes:
I've pushed updates that fix the sqlite issue as well as a few other 
minor adjustments to the build process.

I'll look into the tlssup.c.patch issue soon.

On 3/8/2013 5:55 AM, Benjamin Thaut wrote:
 So I completely reinstalled MinGW. Now the patch correctly applies, but
 now make will freeze in random places of the build process. It will just
 hang there with 13% cpu usage and will never continue.

This has been corrected as well. The current version of make distributed with MinGW has issues with -j options and multicore processors. If you edit /crossdev/gccbuilder/build-tdm64.sh and remove the JOBCOUNT line it will compile successfully although slower.
Mar 08 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.03.2013 20:08, schrieb Daniel Green:
 I've pushed updates that fix the sqlite issue as well as a few other
 minor adjustments to the build process.

 I'll look into the tlssup.c.patch issue soon.

 On 3/8/2013 5:55 AM, Benjamin Thaut wrote:
 So I completely reinstalled MinGW. Now the patch correctly applies, but
 now make will freeze in random places of the build process. It will just
 hang there with 13% cpu usage and will never continue.

This has been corrected as well. The current version of make distributed with MinGW has issues with -j options and multicore processors. If you edit /crossdev/gccbuilder/build-tdm64.sh and remove the JOBCOUNT line it will compile successfully although slower.

Ok, the new build script solved a lot of issues. Unforunately the multiline-stirng issue in options.c remains. Are you sure that you are not using a 3.x.x gcc? Do you have a different version of make installed which works correctly with -j? Kind Regards Benjamin Thaut
Mar 09 2013
parent reply Daniel Green <venix1 gmail.com> writes:
On 3/9/2013 5:06 AM, Benjamin Thaut wrote:
 Ok, the new build script solved a lot of issues. Unforunately the
 multiline-stirng issue in options.c remains. Are you sure that you are
 not using a 3.x.x gcc?

binary and forces that during the build by setting PATH options. Can you provide me with the full error message and the generated options.c file? /crossdev/gdc64/v2/build/gcc/options.c That way I can compare it with what is generated on my sytem.
 Do you have a different version of make installed which works correctly
 with -j?

try downgrading make(Not sure which version works). I simply remove the JOBCOUNT argument from the build scripts and avoid using -j
Mar 09 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.03.2013 12:51, schrieb Daniel Green:
 On 3/9/2013 5:06 AM, Benjamin Thaut wrote:
 Ok, the new build script solved a lot of issues. Unforunately the
 multiline-stirng issue in options.c remains. Are you sure that you are
 not using a 3.x.x gcc?

binary and forces that during the build by setting PATH options. Can you provide me with the full error message and the generated options.c file? /crossdev/gdc64/v2/build/gcc/options.c That way I can compare it with what is generated on my sytem.
 Do you have a different version of make installed which works correctly
 with -j?

try downgrading make(Not sure which version works). I simply remove the JOBCOUNT argument from the build scripts and avoid using -j

Here are the error messages: http://pastebin.com/ruRqbk2U And here is the content of options.c: http://pastebin.com/NJ3PU4zg Btw: Thank you for your support. It might also be usefull what warnings the optionlist script generates: gawk -f ../../gcc-4.6.1/gcc/opt-functions.awk -f ../../gcc-4.6.1/gcc/optc-gen.awk \ -v header_name="config.h system.h coretypes.h tm.h" < optionlist > options.c :arning: multiple different help strings for Generate runtime code for assert()'sobos Derrorbout casts that will produce a null or nil result. :arning: multiple different help strings for Derrorbout casts that will produce a null or nil result. D Kind Regards Benjamin Thaut
Mar 09 2013
parent reply Daniel Green <venix1 gmail.com> writes:
I managed to exactly reproduce the error by setting gcc/d/lang.opt to 
CRLF line endings.

You need to make sure everything is LF line endings.  I've set a 
.gitattributes file which hopefully will fix this for future checkouts.
Mar 09 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.03.2013 15:00, schrieb Daniel Green:
 I managed to exactly reproduce the error by setting gcc/d/lang.opt to
 CRLF line endings.

 You need to make sure everything is LF line endings.  I've set a
 .gitattributes file which hopefully will fix this for future checkouts.

So now it actually compiles all the way through, but failes while linking: C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/gdc64/v2/build/prev-x86_64-w64-mingw32/libstdc++-v3/s c/.libs\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/gdc64/v2/build/prev-x86_64-w64-mingw32/libstdc++-v3/s c/.libs\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/MinGW64/lib/gcc/x86_64-w64-mingw32/4.6.1\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lstdc++ Kind Regards Benjamin Thaut
Mar 10 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.03.2013 12:12, schrieb Benjamin Thaut:
 Am 09.03.2013 15:00, schrieb Daniel Green:
 I managed to exactly reproduce the error by setting gcc/d/lang.opt to
 CRLF line endings.

 You need to make sure everything is LF line endings.  I've set a
 .gitattributes file which hopefully will fix this for future checkouts.

So now it actually compiles all the way through, but failes while linking: C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/gdc64/v2/build/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/gdc64/v2/build/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible C:/crossdev/MinGW64/lib/gcc/x86_64-w64-mingw32/4.6.1\libstdc++.a when searching for -lstdc++ C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lstdc++ Kind Regards Benjamin Thaut

Soory seemed to be CRLF line ending issues again. I re-cloned the repro and now everything seems to be correctly LF. I will put up a full list of instructions how to build mingw-GDC soon. Kind Regards Benjamin Thaut
Mar 10 2013
parent Daniel Green <venix1 gmail.com> writes:
On 3/10/2013 12:08 PM, Benjamin Thaut wrote:
 So now it actually compiles all the way through, but failes while
 linking:

 C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible
 


 when searching for -lstdc++
 C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible
 


 when searching for -lstdc++
 C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: skipping incompatible
 C:/crossdev/MinGW64/lib/gcc/x86_64-w64-mingw32/4.6.1\libstdc++.a when
 searching for -lstdc++
 C:\crossdev\MinGW64\x86_64-w64-mingw32\bin\ld.exe: cannot find -lstdc++

 Kind Regards
 Benjamin Thaut

Soory seemed to be CRLF line ending issues again. I re-cloned the repro and now everything seems to be correctly LF.

Actually that was because of issues with doing a bootstrap build. When you re-cloned it you got the updated script that properly disabled it.
Mar 11 2013