Regarding Bug 4810 and building the evil GCC 4.4

[Daniel Reimer]

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]

Is this RosBE 1.4.4 problem?

On Sun, Aug 23, 2009 at 5:11 PM, Daniel
Reimer<daniel.reimer(a)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.

[Daniel Reimer]

James Tabor wrote:
>   Is this RosBE 1.4.4 problem?
>
>  On Sun, Aug 23, 2009 at 5:11 PM, Daniel
>  Reimer<daniel.reimer(a)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(a)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.

[James Tabor]

So, basically the answer is no, this is not a RosBE issue.

On Sun, Aug 23, 2009 at 5:36 PM, Daniel
Reimer<daniel.reimer(a)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

[Daniel Reimer]

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
>  Reimer<daniel.reimer(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[James Tabor]

Hi!!!
OMG!

On Sun, Aug 23, 2009 at 9:14 PM, Daniel
Reimer<daniel.reimer(a)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~

[Bernd Blaauw]

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

[Dmitry Gorbachev]

ReactOS works with the latest QEMU. I compile QEMU from trunk.

About bug 4810, a fix have been sent to Daniel.

[Bernd Blaauw]

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