Page 1 of 1
Building PS2 GCC 3.x on a GCC 4.x platform
Posted: Sun Jan 28, 2007 9:05 pm
by TyRaNiD
It seems that ps2 toolchain just wont build on a gcc4 system by default, but there is a fix. I haven't merged this into subversion yet as I dont know how the toolchain is structured for the ps2, ill leave that to someone else ;)
The problem is from 3.4 onwards they decprecated the use of casted lvalues which a few bits of the gcc source used. You need to do two things, update the copy of obstack.h and patch decl.c.
The patch for decl.c is:
Code: Select all
460a461,464
> #define set_current_binding_level(x) \
> if(cfun && cp_function_chain->bindings) { cp_function_chain->bindings = (x); } \
> else { scope_chain->bindings = (x); }
>
510c514
< current_binding_level = newlevel;
---
> set_current_binding_level(newlevel);
566c570
< current_binding_level = current_binding_level->level_chain;
---
> set_current_binding_level(current_binding_level->level_chain);
581c585,587
< current_binding_level = class_binding_level;
---
> {
> set_current_binding_level(class_binding_level);
> }
603c609
< current_binding_level = current_binding_level->level_chain;
---
> set_current_binding_level(current_binding_level->level_chain);
616c622
< current_binding_level = b;
---
> set_current_binding_level(b);
4294c4300
< current_binding_level = level;
---
> set_current_binding_level(level);
4296c4302
< current_binding_level = b;
---
> set_current_binding_level(b);
6539c6545
< current_binding_level = NULL_BINDING_LEVEL;
---
> set_current_binding_level(NULL_BINDING_LEVEL);
10125c10131
< current_binding_level = b->level_chain;
---
> set_current_binding_level(b->level_chain);
10128c10134
< current_binding_level = b;
---
> set_current_binding_level(b);
13758c13764
< current_binding_level = bl;
---
> set_current_binding_level(bl);
Copy that patch into the file decl.c.patch inside the ps2toolchain folder.
And then I just modified toolchain.sh to do copying and patching, e.g. at line 155 I added:
Code: Select all
cd $GCC; cp /usr/include/obstack.h include/ || { echo "ERROR COPYING obstack.h"; exit; }
cd ..
cd $GCC; patch gcc/cp/decl.c "$SRCDIR/decl.c.patch" || { echo "ERROR PATCHING decl.c"; exit; }
cd ..
It should now build correctly.
Posted: Sun Jan 28, 2007 10:08 pm
by Lukasz
Nice work Tyranid, now we can all avoid the hassle of switching back to gcc 3.3 every time we need to build the toolchains. I hope someone gets this fix into the toolchain patches soon :-)
Posted: Sat Feb 03, 2007 1:05 am
by sneeze
I took some alternatives of these patches (see references below) and merged them with the result from the gcc-3.2.2.patch.
You can find it here
http://h1.ripway.com/sneezer/gcc-3.2.2_on_4.x.patch
Feel free to try it out. It should work as a direct replacement of the 3.2.2.patch file
The actual patches are stolen from
http://mail-index.netbsd.org/netbsd-bug ... /0008.html (obstack.h)
and
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00210.html (decl.c)
Posted: Wed Apr 18, 2007 7:37 am
by cosmito
Thanks all for the help.
Sneeze : How can I apply a patch under Linux ? I'm really new to Linux...
Posted: Sat Apr 21, 2007 9:55 pm
by cosmito
@sneeze,
How distracted I was... It was simply a matter or replacing the gcc-3.2.2.patch by this new one, right ?
I'm going to try.
Thanks
Posted: Mon Apr 23, 2007 6:47 am
by sneeze
Yes, just replace the gcc-3.2.2.patch file
Did it work ok?
Posted: Mon Apr 23, 2007 10:01 am
by cosmito
Hi sneeze,
In fact, I've got an error during building again ...
But I didn't started the building (by running the toolchain.sh) from scratch. Instead I re-runned the toolchain.sh from my previous attempt (before replacing the file) which gave the a building/compiling error... It may not be conclusive. I should start from scratch. The error now might be due to any previous trash I had from the first attempt (before replacing the file)
I'll try next weekend probably. Too little time lately :(
Thanks for asking.
I'll post as soon I get new results.
Posted: Sun Apr 29, 2007 4:21 pm
by ooPo
I've updated the ps2toolchain in the respository with the changes Tyranid suggested. It builds fine on an Ubuntu Feisty system running gcc-4.1.2.
Enjoy!
Posted: Sun Apr 29, 2007 8:51 pm
by cosmito
Thanks ooPo!
In fact, today I was going to post the results of my last attempt with Cygwin.
It gave me the same error, after installing from scratch everything (the cygwin itself, checking out the svn sources and building the toolchain - I made this on a virtual machine). If anyone is interested, i'll post here the verbose output of it.
From this experience I conclude that the gcc-3.2.2.patch replacement suggested by sneeze doesn't work on the GCC 3.4.4-3 the latest Cygwin has. But now, with the new toolchain i'm going to try again.
Painful hours (why is cygwin building so slow?) of building are waiting me :)
bwt : I managed to build (in a snap) the previous toolchain last week under Debian linux (running under Virtual PC). No need to patch anything, no problem at all :)
But I think I'll prefer to work in a cygwin environment, I guess.
I'll post the results ASAP.
Thanks again
Posted: Mon Apr 30, 2007 9:01 am
by cosmito
@ooPo,
Hi
I just tried to execute the toolchain.sh but it seems there are problems under cygwin.
Code: Select all
$ ./toolchain.sh
: command not founde 4:
: command not founde 8:
: command not founde 13:
: command not founde 17:
: command not founde 22:
: command not founde 26:
'/toolchain.sh: line 42: syntax error near unexpected token `in
'/toolchain.sh: line 42: ` case "$1" in
I checked the differences between this and the previous version with WinMerge and it gives the warning : "These files uses different carriage return types". Might this be the problem ?
Posted: Mon Apr 30, 2007 9:38 am
by ubergeek42
Yes, from my experience, cygwin shell scripts only work when the line endings are LF(Line feed) only, as opposed to (CRLF)
Posted: Mon Apr 30, 2007 10:22 am
by ooPo
Cygwin isn't officially supported, although it may work if you tweak it a bit.
I suggest downloading a premade package if you're set on using it, though.
Posted: Mon Apr 30, 2007 10:26 pm
by cosmito
OK, i'll strip the CR characters and give it a shot.
Posted: Thu May 03, 2007 9:00 am
by cosmito
Well, it didn't worked on Cygwin. I got rid of one of those line end two characters and just leaving the LF one, just like in the previous toolchain versions.
The building now starts under Cygwin but it fails.
For the interested :
Code: Select all
(...)v3/libmath
-g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -f
diagnostics-show-location=once -G0 -g -c ../../../../libstdc++-v3/src/locale-ins
t.cc -o locale-inst.o
/tmp/ps2dev/gcc-3.2.2/build-ee-c++/ee/libstdc++-v3/include/bits/locale_facets.tc
c: In
member function `_InIter std::money_get<_CharT, _InIter>::do_get(_InIter,
_InIter, bool, std::ios_base&, std::_Ios_Iostate&, std::basic_string<_CharT,
std::char_traits<_CharT>, std::allocator<_CharT> >&) const [with _CharT =
char, _InIter = std::istreambuf_iterator<char, std::char_traits<char> >]':
../../../../libstdc++-v3/src/locale-inst.cc:47: instantiated from here
/tmp/ps2dev/gcc-3.2.2/build-ee-c++/ee/libstdc++-v3/include/bits/locale_facets.tc
c:1167: Internal
compiler error in schedule_block, at haifa-sched.c:1714
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
gmake[3]: *** [locale-inst.lo] Error 1
gmake[3]: Leaving directory `/tmp/ps2dev/gcc-3.2.2/build-ee-c++/ee/libstdc++-v3/
src'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/tmp/ps2dev/gcc-3.2.2/build-ee-c++/ee/libstdc++-v3'
gmake[1]: *** [all-recursive-am] Error 2
gmake[1]: Leaving directory `/tmp/ps2dev/gcc-3.2.2/build-ee-c++/ee/libstdc++-v3'
gmake: *** [all-target-libstdc++-v3] Error 2
ERROR BUILDING GCC (gcc-3.2.2 ee C++)
Well, I had enough of Cygwin. Bailing out :)
At least on Debian linux it build (well, just the toolchain previous version builded now I hope it still does :) )
The GCC version on Cygwin is 3.4.4.
Posted: Thu May 03, 2007 9:08 am
by cosmito
@TyRaNiD,
Well, maybe i'll try your patch, just maybe.
And BTW, congratulations for your interesting presentation on BP2007!
I quite new to PS2 delopment (just finally buit the toolchain on Linux and in the mean while looked at the SDK examples, tutorials and built some using a precompiled Win32 for Cygwin) but it seems that the PSP is a bit more documented... Just my impression ?
Why my obcession about documentation when anyone can look at the examples ? Quite simple : Documentation is essecial for true knowledge and correct way of doing thigs. Anyone can look at the examples and figure how things works, but it's depending on our understanding and interpretation of it, not the direct explanation. Also, no example is ever complete compared to a reference document.