Hi. After two weeks of disappointing escapades over building GCC 4.4.X I decided to try out the official mingw32 build from sf.net always in my mind that all patches we had to use in GCC 4.1.3 are already included in GCC 4.4.X. Well at first it built well (with disabled rsym, which fucks up dwarf2 headers in a way which renders a executable unuseable) but then it died with the error you can see in the bug report. (http://www.reactos.org/bugzilla/show_bug.cgi?id=4810) OK, I hoped someone comes up with a fix in our code, but hto answered with a patch in gcc. My 1. question now: Is this patch needed or is the error our fault? If we really need this patch i could need someone's helping hand with building GCC. We started a wiki entry (http://www.reactos.org/wiki/Compiling_GCC_From_Windows) which shows our recent tries to build a recent GCC without dwarf2 support. it builds quite well if i do "make all-gcc", but i want and need a full "make all" and there i get this one: http://img24.imageshack.us/img24/8817/1007360g.jpg Any Ideas? (Yes this is question 2.) Question 3 is: Anyone succeeded building cloog-ppl? And the last question: Any other useless crap in our settings in the wiki? Any needed fixes settings etc?
Thx.
Is this RosBE 1.4.4 problem?
On Sun, Aug 23, 2009 at 5:11 PM, Daniel Reimerdaniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Hi. After two weeks of disappointing escapades over building GCC 4.4.X I decided to try out the official mingw32 build from sf.net always in my mind that all patches we had to use in GCC 4.1.3 are already included in GCC 4.4.X. Well at first it built well (with disabled rsym, which fucks up dwarf2 headers in a way which renders a executable unuseable) but then it died with the error you can see in the bug report. (http://www.reactos.org/bugzilla/show_bug.cgi?id=4810) OK, I hoped someone comes up with a fix in our code, but hto answered with a patch in gcc. My 1. question now: Is this patch needed or is the error our fault? If we really need this patch i could need someone's helping hand with building GCC. We started a wiki entry (http://www.reactos.org/wiki/Compiling_GCC_From_Windows) which shows our recent tries to build a recent GCC without dwarf2 support. it builds quite well if i do "make all-gcc", but i want and need a full "make all" and there i get this one: http://img24.imageshack.us/img24/8817/1007360g.jpg Any Ideas? (Yes this is question 2.) Question 3 is: Anyone succeeded building cloog-ppl? And the last question: Any other useless crap in our settings in the wiki? Any needed fixes settings etc?
Thx.
James Tabor wrote:
Is this RosBE 1.4.4 problem?
On Sun, Aug 23, 2009 at 5:11 PM, Daniel Reimerdaniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Hi. After two weeks of disappointing escapades over building GCC 4.4.X I decided to try out the official mingw32 build from sf.net always in my mind that all patches we had to use in GCC 4.1.3 are already included in GCC 4.4.X. Well at first it built well (with disabled rsym, which fucks up dwarf2 headers in a way which renders a executable unuseable) but then it died with the error you can see in the bug report. (http://www.reactos.org/bugzilla/show_bug.cgi?id=4810) OK, I hoped someone comes up with a fix in our code, but hto answered with a patch in gcc. My 1. question now: Is this patch needed or is the error our fault? If we really need this patch i could need someone's helping hand with building GCC. We started a wiki entry (http://www.reactos.org/wiki/Compiling_GCC_From_Windows) which shows our recent tries to build a recent GCC without dwarf2 support. it builds quite well if i do "make all-gcc", but i want and need a full "make all" and there i get this one: http://img24.imageshack.us/img24/8817/1007360g.jpg Any Ideas? (Yes this is question 2.) Question 3 is: Anyone succeeded building cloog-ppl? And the last question: Any other useless crap in our settings in the wiki? Any needed fixes settings etc?
Thx.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What is rosbe 1.4.4 problem? I build GCC with msys and GCC 3.4.5, so no rosbe here. The patches were in rosbe, yes. ANd the Ntoskrnl error is in rosbe, but as mentioned in the report with MinGW's official GCC 4.4.0 binaries.
So, basically the answer is no, this is not a RosBE issue.
On Sun, Aug 23, 2009 at 5:36 PM, Daniel Reimerdaniel.reimer@stud-mail.uni-wuerzburg.de wrote:
James Tabor wrote:
Is this RosBE 1.4.4 problem?
What is rosbe 1.4.4 problem? I build GCC with msys and GCC 3.4.5, so no rosbe here. The patches were in rosbe, yes. ANd the Ntoskrnl error is in rosbe, but as mentioned in the report with MinGW's official GCC 4.4.0 binaries.
You are using RosBE patches to create a new compiler under windows and you are running into problems using this new compiler building ReactOS ntoskrnl. That is how I read the bug report....... It's not much to read I see.....
So technically this is a nice way for you to request help from us since you are using RosBE as an example for building your new compiler?.?...
Are you trying to build a newer RosBE in support of the ReactOS project? If so, should the bug report be under something else other than Component: Kernel? Since the supported RosBE does work for the rest of us....
I understand being thrust rated after weeks of work and looking at everything and coming up with nothing to gain from it! Hacking your ass off to the better end! So next time please be more informative and let us know more what your are trying to do. Don't blame the ReactOS kernel for a compiler issue too!
Thanks, James
Hi, errr. You know that I am the Mantainer of RosBE for Windows, yes? And no, I don't use ANY RosBE Patches, I just asked what you guys think about the one hto posted, because I would prefer a clean GCC from the official reposority. Another NO for this strange Idea that I use RosBE as example to build a new GCC. And, YES I try to build a new RosBE, Aleksey asked me ages ago to finally update to a newer GCC and all I wanted from you is your opinion regarding this error, the wiki page encoded, Colin and me created and htos Patch. Precise enough?!
Thx
Daniel Reimer
James Tabor wrote:
So, basically the answer is no, this is not a RosBE issue.
On Sun, Aug 23, 2009 at 5:36 PM, Daniel Reimerdaniel.reimer@stud-mail.uni-wuerzburg.de wrote:
James Tabor wrote:
Is this RosBE 1.4.4 problem?
What is rosbe 1.4.4 problem? I build GCC with msys and GCC 3.4.5, so no rosbe here. The patches were in rosbe, yes. ANd the Ntoskrnl error is in rosbe, but as mentioned in the report with MinGW's official GCC 4.4.0 binaries.
You are using RosBE patches to create a new compiler under windows and you are running into problems using this new compiler building ReactOS ntoskrnl. That is how I read the bug report....... It's not much to read I see.....
So technically this is a nice way for you to request help from us since you are using RosBE as an example for building your new compiler?.?...
Are you trying to build a newer RosBE in support of the ReactOS project? If so, should the bug report be under something else other than Component: Kernel? Since the supported RosBE does work for the rest of us....
I understand being thrust rated after weeks of work and looking at everything and coming up with nothing to gain from it! Hacking your ass off to the better end! So next time please be more informative and let us know more what your are trying to do. Don't blame the ReactOS kernel for a compiler issue too!
Thanks, James
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!!! OMG!
On Sun, Aug 23, 2009 at 9:14 PM, Daniel Reimerdaniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Hi, errr. You know that I am the Mantainer of RosBE for Windows, yes?
I am very sorry!!! I did not know, EmuandCo! I did not realize it from your name....... Sorry, James
Need to read the web site more often~
Op 24-8-2009 0:11, Daniel Reimer schreef:
Hi.
While at it, do you guys have a QEMU build tutorial as well? Just asking, as ReactOS 0.3.10 seems to be bundled with QEMU 0.9.0 while already QEMU 0.10.5 is out. I don't know if ReactOS works with a more recent QEMU, didn't try yet. Win32/64 Binaries seem to be available at http://www.bttr-software.de/qemu/ for QEMU 0.10.5 (zlib1.dll required for some reason).
The issue is that Coreboot and SeaBIOS (www.coreboot.org) don't work under older QEMU, but work flawlessly under recent QEMU. I finally tried QEMU rather than VMware due to the Coreboot bios replacement with enabled floppy emulation in flash, as was announced on Coreboot and FreeDOS mailinglists. Benefit is 1) tiny OS in flash with possibly partitioning tools [kernel, shell, fdisk, format, sys], 2) testing if ReactOS is Coreboot/Seabios-proof as operating system under a opensource BIOS.
So far ReactOS dropped back to 4color in VMware if I remember correctly when replacing QEMU (0.10.5) 's 'bios.bin' by that of Coreboot [ http://linuxtogo.org/~kevin/SeaBIOS/test/coreboot-qemu-freedos-20090818.bin ]
Bernd
ReactOS works with the latest QEMU. I compile QEMU from trunk.
About bug 4810, a fix have been sent to Daniel.
Op 24-8-2009 17:32, Dmitry Gorbachev schreef:
ReactOS works with the latest QEMU. I compile QEMU from trunk.
About bug 4810, a fix have been sent to Daniel.
If it also implies that ReactOS 0.3.11 (hopefully including its original goals of latest FireFox and OpenOffice working on it, though logs show currently main effort on MSVC and audio) will be released with QEMU 0.10.5 then it's great. http://downloads.sourceforge.net/reactos/ReactOS-0.3.10-REL-qemu.zip somehow was released with QEMU 0.9.0.
Goodluck with your GCC updating, ending this thread hijacking now :)
Bernd