GCC 4.4.x -- What's missing?

[Alex Ionescu]

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

[Daniel Reimer]

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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu

[Daniel Reimer]

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
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Best regards,
> Alex Ionescu
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Olaf Siejka]

Can't agree more with Alex. Lets switch over on a New Year:>

2009/12/31 Daniel Reimer [e-mail]
> 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.

[Aleksey Bragin]

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 [e-mail]
> 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.

[Colin Finck]

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]

Colin Finck schrieb:
> 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.

Would be great if we could upgrade to 2.20.51.20091118 or newer

[Colin Finck]

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]

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

[Daniel Reimer]

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 
[e-mail]                     *
*******************************************************************************

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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Daniel Reimer]

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 for
>
> Windows     *
>                         Package
>
> "rosbe_1.5"                             *
>                  by Colin Finck
>
> [e-mail]                      *
>
> 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Dmitry Gorbachev]

There exist prebuilt packages of w32api and mingwrt, probably there is
no need to build them.

[Dmitry Gorbachev]

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.

[Colin Finck]

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

[Alex Ionescu]

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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Best regards,
Alex Ionescu

[Dmitry Gorbachev]

But why don't you entrust configuration of GMP (and everything else)
to GCC's configure script?