Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Earnie
Ruben Van Boxem wrote: > > Ah, yes, you're that Earnie :) > Yes, I'm that Earnie. > Will config.guess convert the MINGW64 thing correctly to the correct > gcc target? What about current projects, that aren't specifically > designed for this setting, will they break or just not work like they

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Ruben Van Boxem
> > I understand your reasoning do you understand mine? My reasoning is > toward the comfortableness of the noob who just wants to build 64bit > native binaries with the least amount of typing. I am sure that MSYS > works fine as you have documented it. But I did create the beast and > MSYSTEM w

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Luis Lavena
On Wed, Jul 28, 2010 at 1:39 PM, Ruben Van Boxem wrote: > > MSYS itself is 32-bit, so having uname return something else is not quite > correct. There are other things bad about this suggestion: > > 1. What if you have installed x86_64-w64-mingw32-gcc, i686-w64-mingw32-gcc, > and i686-pc-mingw32-g

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Earnie
Ruben Van Boxem wrote: > > http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS > > > Great, someone actually found the wiki! > > MSYS itself is 32-bit, so having uname return something else is not > quite correct. There are other things bad about this suggestion: 1. > What if you have install

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Ruben Van Boxem
> > > environment variable MSYSTEM. So if MSYSTEM is changed to say mingw64 > > then the config.guess and config.sub scripts could be changed to > > recognize the uname string to produce i686-pc-mingw64, x86_64-mingw64 or > > even x86_64-w64-mingw32 which ever is preferred. The uname string from

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Luis Lavena
On Wed, Jul 28, 2010 at 9:44 AM, Earnie wrote: > JonY wrote: > >> >>  MSYS has been strongly associated with mingw.org for a very long >>  time, hence to autotools, MSYS uname string can be assumed to be >>  i686-pc-mingw32. >> > Hello JonY and Ernie, Thank you both for your responses. > Let me

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread JonY
On 7/28/2010 20:32, Dongsheng Song wrote: > 于 2010-7-28 16:02, Kai Tietz 写道: >> 2010/7/28 Dongsheng Song: >>> 于 2010-7-28 15:43, Kai Tietz 写道: 2010/7/28 Dongsheng Song: > Hi Kai, > > When we cross build gcc 4.5 for windows, I found we can build windows gcc > binary one > w

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

2010-07-28 Thread Earnie
JonY wrote: > > MSYS has been strongly associated with mingw.org for a very long > time, hence to autotools, MSYS uname string can be assumed to be > i686-pc-mingw32. > Let me state that the string from the MSYS uname is controlled by an environment variable MSYSTEM. So if MSYSTEM is changed

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Dongsheng Song
于 2010-7-28 16:02, Kai Tietz 写道: > 2010/7/28 Dongsheng Song : >> 于 2010-7-28 15:43, Kai Tietz 写道: >>> 2010/7/28 Dongsheng Song : Hi Kai, When we cross build gcc 4.5 for windows, I found we can build windows gcc binary one week ago, but now the build failed. After

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Kai Tietz
2010/7/28 Ozkan Sezer : > On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song > wrote: >> 于 2010-7-28 15:43, Kai Tietz 写道: >>> 2010/7/28 Dongsheng Song : Hi Kai, When we cross build gcc 4.5 for windows, I found we can build windows gcc binary one week ago, but now the build

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Ozkan Sezer
On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song wrote: > 于 2010-7-28 15:43, Kai Tietz 写道: >> 2010/7/28 Dongsheng Song : >>> Hi Kai, >>> >>> When we cross build gcc 4.5 for windows, I found we can build windows gcc >>> binary one >>> week ago, but now the build failed. >>> >>> After I do a binary

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Kai Tietz
2010/7/28 Dongsheng Song : > 于 2010-7-28 15:43, Kai Tietz 写道: >> 2010/7/28 Dongsheng Song : >>> Hi Kai, >>> >>> When we cross build gcc 4.5 for windows, I found we can build windows gcc >>> binary one >>> week ago, but now the build failed. >>> >>> After I do a binary search, I found the issue cau

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Dongsheng Song
于 2010-7-28 15:43, Kai Tietz 写道: > 2010/7/28 Dongsheng Song : >> Hi Kai, >> >> When we cross build gcc 4.5 for windows, I found we can build windows gcc >> binary one >> week ago, but now the build failed. >> >> After I do a binary search, I found the issue caused by r2945. >> >>r2950 | 2010-0

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Kai Tietz
2010/7/28 Dongsheng Song : > Hi Kai, > > When we cross build gcc 4.5 for windows, I found we can build windows gcc > binary one > week ago, but now the build failed. > > After I do a binary search, I found the issue caused by r2945. > >    r2950 | 2010-07-24 05:50:28 | FAILED >    r2945 | 2010-07-

[Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

2010-07-28 Thread Dongsheng Song
Hi Kai, When we cross build gcc 4.5 for windows, I found we can build windows gcc binary one week ago, but now the build failed. After I do a binary search, I found the issue caused by r2945. r2950 | 2010-07-24 05:50:28 | FAILED r2945 | 2010-07-24 02:44:15 | FAILED r2944 | 2010-07-2