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.


That shouldn't be necessary.  It may have something to do with using 
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.


That was due to some extra spaces in after the \.  Fixed in the script.


 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


Ya, I never added the g++ downloads.  Fixed as well.

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.


 That shouldn't be necessary.  It may have something to do with using
 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.


 That was due to some extra spaces in after the \.  Fixed in the script.


 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


 Ya, I never added the g++ downloads.  Fixed as well.

 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?


If you follow the build script you'll see it extracts the TDM 4.6.1 
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?


I do not, last I checked it was known bug without a solution.  You could 
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?


 If you follow the build script you'll see it extracts the TDM 4.6.1
 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?


 I do not, last I checked it was known bug without a solution.  You could
 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
 




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.


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