Hi,
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts), and I've gotten it to work on SnowLeopard with some minor hacks -- ie, all that's missing is for Colin, when he has time, to integrate the little fixes for these non-standard hosts.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Best regards, Alex Ionescu
Good question. I wonder, too. Problem could be that this patch forces ppl to use a new RosBE. At least last time i tried, it broke gcc 4.1.X build.
Alex Ionescu schrieb:
Hi,
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts), and I've gotten it to work on SnowLeopard with some minor hacks -- ie, all that's missing is for Colin, when he has time, to integrate the little fixes for these non-standard hosts.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Forcing people to use a new RosBE is a *good* thing.
On 2009-12-31, at 12:15 AM, Daniel Reimer wrote:
Good question. I wonder, too. Problem could be that this patch forces ppl to use a new RosBE. At least last time i tried, it broke gcc 4.1.X build.
Alex Ionescu schrieb:
Hi,
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts), and I've gotten it to work on SnowLeopard with some minor hacks -- ie, all that's missing is for Colin, when he has time, to integrate the little fixes for these non-standard hosts.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Sure it is. But explain this to the lazy bums out there :-P
Nah, honestly, I dont think theres a real reason except the big step having to update gcc.
Alex Ionescu schrieb:
Forcing people to use a new RosBE is a *good* thing.
On 2009-12-31, at 12:15 AM, Daniel Reimer wrote:
Good question. I wonder, too. Problem could be that this patch forces ppl to use a new RosBE. At least last time i tried, it broke gcc 4.1.X build.
Alex Ionescu schrieb:
Hi,
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts), and I've gotten it to work on SnowLeopard with some minor hacks -- ie, all that's missing is for Colin, when he has time, to integrate the little fixes for these non-standard hosts.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Can't agree more with Alex. Lets switch over on a New Year:>
2009/12/31 Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de
Sure it is. But explain this to the lazy bums out there :-P
Nah, honestly, I dont think theres a real reason except the big step having to update gcc.
Alex Ionescu schrieb:
Forcing people to use a new RosBE is a *good* thing.
I fully support moving forward too. If some lazy ppl don't want to use a newer RosBE, it's their own problem.
On Dec 31, 2009, at 12:03 PM, Olaf Siejka wrote:
Can't agree more with Alex. Lets switch over on a New Year:>
2009/12/31 Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de Sure it is. But explain this to the lazy bums out there :-P
Nah, honestly, I dont think theres a real reason except the big step having to update gcc.
Alex Ionescu schrieb:
Forcing people to use a new RosBE is a *good* thing.
Alex Ionescu wrote:
As far as I am aware, GCC 4.4.x now works on Linux through RosBE 1.5 (minus some missing patches for 64-bit hosts)
Yes, I've been fixing the 64-bit problems in RosBE 1.5, but got stuck at GMP. Its auto-detection for the ABI value seems to be broken, because it wrongly detects ABI=64 on a i386 Linux host for me. Need to find a way to work around this problem before I can finish the new RosBE version. Had no time for this over the holidays, maybe next week.
As for Windows, I think there is a fully working binary GCC 4.4.x/RosBE that builds trunk just fine.
Yes, it's more or less done. However, as we want to keep consistence, its Binutils version still needs to be upgraded to the same snapshot version, which is going to be used by RosBE-Unix.
So what's missing for 4.4.x to become official, RosBE 1.5 to RTM, and for the 4.4.x patch from BZ to be committed (The one that gets trunk building)?
Apart from this, it would be nice if KJK could add the code for his suggested "rosbe-clean" target to our Makefile as soon as possible. This way, the logic of RosBE's often criticized "clean" command would be simplified and go into our Makefile. RosBE's "clean" would just call "make rosbe-clean" then and always clean the tree you expect (people with multiple source trees know what I'm talking about).
As this modified "clean" command would also break compatibility with older ReactOS revisions, I'd like to see the Makefile target being committed to trunk before we release RosBE 1.5 (and break building with older RosBE versions as well). The "clean" scripts of the new RosBE version could already make use of this target then.
Best regards,
Colin
Timo Kreuzer wrote:
Would be great if we could upgrade to 2.20.51.20091118 or newer
I've prepared a 20091222 package for RosBE-Unix 1.5. The source package usable for "RosBE-Builder.sh" and "buildtoolchain.sh" has just been uploaded to http://svn.reactos.org/RosBE-Sources/rosbe_1.5.
Daniel, if you're interested, try to use the buildtoolchain script under MSYS to make a new Binutils build for RosBE-Windows using this source package.
Best regards,
Colin
Colin Finck wrote:
Daniel, if you're interested, try to use the buildtoolchain script under MSYS to make a new Binutils build for RosBE-Windows using this source package.
And don't forget that I've also updated the MPFR library required for building to the final version 2.4.2. The new source package is available at the same location. See also my recent changes to the "buildtoolchain.sh" script.
Best regards,
Colin
Well, if you explain me why your script deletes anything in my include folder of the mingw in C:\Mingw which i wanna use for building....
Daniel@DANIELS-PC /c/Users/Daniel/Desktop/src $ ./buildtoolchain.sh /c/packs /c/build ******************************************************************************* * Buildtoolchain script for the ReactOS Build Environment for Windows * * Package "rosbe_1.5" * * by Colin Finck colin@reactos.org * *******************************************************************************
This script builds a binutils/GCC/mingw-runtime/w32api toolchain for Windows.
Checking for the needed tools... Checking for bison... OK Checking for flex... OK Checking for gcc... OK Checking for g++... OK Checking for grep... OK Checking for makeinfo... OK Checking for GNU Make... OK
Checking for the correct GCC version... OK
Building... Extracting w32api... OK Running "gcc -s -o /c/build/support/cpucount.exe /c/Users/Daniel/Desktop/src/too ls/cpucount.c"... FAILED Please take a look at the log file "/c/build/build.log" If you did not do something wrong, please save the log file and contact the Reac tOS Team. Aborted!
LOG:
c:/Users/Daniel/Desktop/src/tools/cpucount.c:13:24: windows.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c:20:19: stdio.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c:21:20: string.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c: In function `main': c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: `stderr' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: (Each undeclared identifier is reported only once c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: for each function it appears in.) c:/Users/Daniel/Desktop/src/tools/cpucount.c:40: error: `DWORD_PTR' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:40: error: syntax error before "ProcessAffinityMask" c:/Users/Daniel/Desktop/src/tools/cpucount.c:42: error: `ProcessAffinityMask' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:42: error: `SystemAffinityMask' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:57: error: `SYSTEM_INFO' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:57: error: syntax error before "SystemInformation" c:/Users/Daniel/Desktop/src/tools/cpucount.c:59: error: `SystemInformation' undeclared (first use in this function)
They WERE THERE.
Colin Finck schrieb:
Timo Kreuzer wrote:
Would be great if we could upgrade to 2.20.51.20091118 or newer
I've prepared a 20091222 package for RosBE-Unix 1.5. The source package usable for "RosBE-Builder.sh" and "buildtoolchain.sh" has just been uploaded to http://svn.reactos.org/RosBE-Sources/rosbe_1.5.
Daniel, if you're interested, try to use the buildtoolchain script under MSYS to make a new Binutils build for RosBE-Windows using this source package.
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
and if I modify line 121: rs_mkdir_empty "$SYSHEADERDIR" to not delete my stuff it continues, but then hangs on gmp's configure, telling me that my gcc is not valid...
Know what? These GCC ********* should die in hell for making such a crap of a build process. RBuild ROCKS^2 compared to this!
Daniel Reimer schrieb:
Well, if you explain me why your script deletes anything in my include folder of the mingw in C:\Mingw which i wanna use for building....
Daniel@DANIELS-PC /c/Users/Daniel/Desktop/src $ ./buildtoolchain.sh /c/packs /c/build
Buildtoolchain script for the ReactOS Build Environment forWindows *
Package"rosbe_1.5" *
by Colin Finck
This script builds a binutils/GCC/mingw-runtime/w32api toolchain for Windows.
Checking for the needed tools... Checking for bison... OK Checking for flex... OK Checking for gcc... OK Checking for g++... OK Checking for grep... OK Checking for makeinfo... OK Checking for GNU Make... OK
Checking for the correct GCC version... OK
Building... Extracting w32api... OK Running "gcc -s -o /c/build/support/cpucount.exe /c/Users/Daniel/Desktop/src/too ls/cpucount.c"... FAILED Please take a look at the log file "/c/build/build.log" If you did not do something wrong, please save the log file and contact the Reac tOS Team. Aborted!
LOG:
c:/Users/Daniel/Desktop/src/tools/cpucount.c:13:24: windows.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c:20:19: stdio.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c:21:20: string.h: No such file or directory c:/Users/Daniel/Desktop/src/tools/cpucount.c: In function `main': c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: `stderr' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: (Each undeclared identifier is reported only once c:/Users/Daniel/Desktop/src/tools/cpucount.c:33: error: for each function it appears in.) c:/Users/Daniel/Desktop/src/tools/cpucount.c:40: error: `DWORD_PTR' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:40: error: syntax error before "ProcessAffinityMask" c:/Users/Daniel/Desktop/src/tools/cpucount.c:42: error: `ProcessAffinityMask' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:42: error: `SystemAffinityMask' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:57: error: `SYSTEM_INFO' undeclared (first use in this function) c:/Users/Daniel/Desktop/src/tools/cpucount.c:57: error: syntax error before "SystemInformation" c:/Users/Daniel/Desktop/src/tools/cpucount.c:59: error: `SystemInformation' undeclared (first use in this function)
They WERE THERE.
Colin Finck schrieb:
Timo Kreuzer wrote:
Would be great if we could upgrade to 2.20.51.20091118 or newer
I've prepared a 20091222 package for RosBE-Unix 1.5. The source package usable for "RosBE-Builder.sh" and "buildtoolchain.sh" has just been uploaded to http://svn.reactos.org/RosBE-Sources/rosbe_1.5.
Daniel, if you're interested, try to use the buildtoolchain script under MSYS to make a new Binutils build for RosBE-Windows using this source package.
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
There exist prebuilt packages of w32api and mingwrt, probably there is no need to build them.
Colin Finck wrote:
Yes, I've been fixing the 64-bit problems in RosBE 1.5, but got stuck at GMP. Its auto-detection for the ABI value seems to be broken, because it wrongly detects ABI=64 on a i386 Linux host for me.
What does not work?
./configure CFLAGS="..." ABI=32 make make check make install
Another way is to copy GMP (and MPFR, and Binutils) into GCC top level directory and allow GCC build scripts to deal with it.
Dmitry Gorbachev wrote:
What does not work?
./configure CFLAGS="..." ABI=32
Well, this would require us to build the entire RosBE-Unix toolchain for 32-bit as well (while all other RosBE-Unix versions built native 64-bit binaries on 64-bit machines so far). It would also make RosBE more CPU-dependent, a thing I'd like to avoid. If you look into GMP's configure script, you'll also see that there are many architectures which don't support a simple ABI=32 value. Even if these architectures might currently not be interesting for us, they can certainly be in the future.
GMP's ABI detection seems to be entirely based on the host CPU, but doesn't consider the host OS. So if you're running a 32-bit OS on a 64-bit CPU, GMP will detect ABI=64 and fail. The only workaround I can currently think of would be checking `uname -m` for "i*86" and setting ABI=32 in this case. Otherwise we'll let GMP autodetect the ABI value.
But maybe someone else has better ideas. I'd be surprised if I'm the first to notice that the common build procedure "configure && make && make install" fails for such a simple configuration as having a 32-bit OS running on a 64-bit CPU.
Best regards,
Colin
Colin, on OS X I built RosBE for 32-bits, and I think we should force that for the moment...
On 2010-01-01, at 8:26 AM, Colin Finck wrote:
Dmitry Gorbachev wrote:
What does not work?
./configure CFLAGS="..." ABI=32
Well, this would require us to build the entire RosBE-Unix toolchain for 32-bit as well (while all other RosBE-Unix versions built native 64-bit binaries on 64-bit machines so far). It would also make RosBE more CPU-dependent, a thing I'd like to avoid. If you look into GMP's configure script, you'll also see that there are many architectures which don't support a simple ABI=32 value. Even if these architectures might currently not be interesting for us, they can certainly be in the future.
GMP's ABI detection seems to be entirely based on the host CPU, but doesn't consider the host OS. So if you're running a 32-bit OS on a 64-bit CPU, GMP will detect ABI=64 and fail. The only workaround I can currently think of would be checking `uname -m` for "i*86" and setting ABI=32 in this case. Otherwise we'll let GMP autodetect the ABI value.
But maybe someone else has better ideas. I'd be surprised if I'm the first to notice that the common build procedure "configure && make && make install" fails for such a simple configuration as having a 32-bit OS running on a 64-bit CPU.
Best regards,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
But why don't you entrust configuration of GMP (and everything else) to GCC's configure script?