Page 1 of 1
Archlinux PKGBUILDS for ps2toolchain
Posted: Tue Feb 17, 2009 5:17 am
by ragnarok2040
Description:
- These are PKGBUILDS for the toolchains and libraries needed for ps2dev. The packages install to /opt/ps2dev by default, but you can change the _prefix variable to whatever path, just remember to change it so it's the same across all the PKGBUILDS. I followed Archlinux's AUR package guidelines when making them. The cross-ps2-ee-gcc-base and cross-ps2-ee-gcc PKGBUILDS keep binutils-2.14's ee-c++filt and libiberty.a as they were the later version.
Changelog:
- I modified the newlib patch to add removal of the hardcoded DESTDIR variables in all the Makefile.in files.
Used a patch off the binutils mailing list to fix DESTDIR support for binutils-2.14.
ps2sdk PKGBUILD released
ps2sdk PKGBUILD modified to automate install of crt0.o for ee-gcc using crt0.install.
A script added to /etc/profile.d/ to setup the ps2dev environment variables.
gsKit PKGBUILD released with ps2sdk-ports PKGBUILDS
PKGBUILDS:
Notes:
- [1]With the latest revisions of libpng, libjpeg, and zlib, the patches are no longer needed so please comment that step from the PKGBUILDS. I'd upload new versions, but I'm having trouble logging into my hosting, heh.
[2]zlib, libpng, libjpeg are optional dependencies for gsKit texture support
Edited for clarity.
Posted: Wed Feb 18, 2009 12:51 am
by yoshi314
nice, i'll have a look and give it some testing in a few days. does it "play nicely" with native toolchain?
Posted: Wed Feb 18, 2009 2:58 am
by ragnarok2040
It should play nicely with the host toolchain, I added options to disable the automated running of the host's strip and libtool in the PKGBUILDS and added commands to just strip the host executable binaries within the PKGBUILDS.
On a side note, I haven't tested compiling it on x86_64, yet. It should work, though.
Posted: Sat Feb 21, 2009 7:47 pm
by ragnarok2040
http://homebrew.thewaffleiron.net/ragna ... svn.tar.gz
I've finished making the PKGBUILD for ps2sdk. I've made it as configurable as the others, using _prefix for custom defining the ps2dev installation directory. The pkgver variable can be defined to a custom revision number, as well. I included an install file that automates the creation and removal of the symlinks to $PS2SDK/ee/startup/crt0.o when the package is installed/uninstalled. It also installs the ps2sdk source, without the subversion metadata, into $_prefix/src so that sources needing PS2SDKSRC will compile.
The environment variables PS2DEV, PS2SDK, and PS2SDKSRC are defined as $_prefix, $_prefix/ps2sdk, $_prefix/src/ps2sdk, and $_prefix/ee/bin:$_prefix/iop/bin:$_prefix/dvp/bin are added to PATH, which are then printed out to a environment script called ps2dev.sh. This gets installed to /etc/profile.d/. It's also backed up when the package is removed, in case anyone wants to keep it.
Posted: Sat Feb 21, 2009 10:21 pm
by Badboy_
ragnarok2040 wrote:...
i saw this line:
Code: Select all
rm -rf `find . -type d -name .svn`
first: backticks are outdated! instead the use of the $()-syntax would be better.
BUT!
why don't you use:
Code: Select all
find . -type d -name .svn -exec rm -rf "{}" \;
edit:
a friend told me that this package will fail on x86_64
Code: Select all
xgcc: Internal error: Speicherzugriffsfehler (program as)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
xgcc: Internal error: Speicherzugriffsfehler (program as)
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [libgcc/./_muldi3.o] Fehler 1
make[2]: *** Warte auf noch nicht beendete Prozesse...
make[2]: *** [libgcc/./_negdi2.o] Fehler 1
...
../scripts/002-gcc-3.2.2-stage1.sh: Failed.
"Internal error: Speicherzugriffsfehler (program as)" == "Internal error: segmentation fault"
Posted: Sun Feb 22, 2009 3:48 pm
by ragnarok2040
I tried using it first, but the command doesn't seem to execute quite right. The find command outputs a list of "No such file or directory" errors. The command that I used did work, though. I guess I can change it to the following, which has no backticks.
Code: Select all
find . -type d -name .svn -print0 | xargs -0 /bin/rm -rf
I just managed to test the cross-ps2-ee-gcc-base PKGBUILD on my brother's x86_64 Archlinux install and it does fail with that segmentation fault, Installing the gcc34 package and prepending CC=gcc-3.4 prior to the configure and make commands works, though.
I can modify the PKGBUILDS to be both i686 and x86_64 compatible by making gcc34 a makedepend and compiling with it, which is probably for the better. There's no telling when a later version of gcc might break building the toolchain on the i686 arch as well.
Posted: Sun Feb 22, 2009 7:22 pm
by ragnarok2040
Okay, new PKGBUILDS are up. All the packages build with gcc-3.4, since it's easier to maintain that way. It should build fine on x86_64 or i686.
Posted: Tue Apr 07, 2009 3:42 pm
by yoshi314
they seem to be working nice so far. what is the order i should build each of them - manual checking deps in pkgbuilds is a bit of a hassle, and from what i've seen some of them conflict with each other (e.g. ee-gcc-base and ee-gcc)
btw there should be a series of similar pkgbuilds for psp toolchain. i hope it's as easy as this one.
Posted: Tue Apr 07, 2009 8:36 pm
by ragnarok2040
The order should be cross-ps2-binutils (builds all ee/iop/dvp binutils), cross-ps2-ee-gcc-base, cross-ps2-ee-newlib (needed for building ee-g++), cross-ps2-ee-gcc (C/C++), and cross-ps2-iop-gcc.
I have a few more pkgbuilds, as well. They're called ps2sdk-ports-libjpeg-svn.tar.gz, ps2sdk-ports-libpng-svn.tar.gz, ps2sdk-ports-zlib-svn.tar.gz, and gsKit-svn.tar.gz. The gsKit-svn pkgbuild uses the previous 3 libraries as optional dependencies and checks to see if they're installed prior to compiling. If they're not installed prior to gsKit, then gsKit is compiled without imagelib support.
A note for anyone with SVN access:
My patches to update the ports of libpng, zlib, and libjpeg has left them a mess since the patches couldn't remove old files and directories along with a few new files that didn't seem to make it into the patch. The pkgbuild archives for libpng, libjpeg, and zlib contain the shell commands and patches to fix the problems on a local copy, but I don't have access to fix it properly.
Posted: Mon May 04, 2009 11:27 am
by deba5er
When trying to install using the order in the last post, I encountered the following error:
# makepkg --asroot -i
-----
error: replacing packages with -U is not supported yet
error: you can replace packages manually using -Rd and -U
error: failed to prepare transaction (conflicting dependencies)
:: cross-ps2-ee-gcc: conflicts with cross-ps2-ee-gcc-base
---
Any ideas on what I'm doing wrong?
Posted: Mon May 04, 2009 6:42 pm
by ragnarok2040
The cross-ps2-ee-gcc-base package needs to be removed first, prior to installing cross-ps2-ee-gcc. The base package is no longer needed after building the full gcc package, anyway. I guess I forgot to mention that, :D.
The reason for the conflict is because the base package and full gcc package have the same files so it's either one or the other. I thought of using "replaces" instead of "conflicts", since the full package does replace the base package's functionality, but the manpage said "replaces" only works for pacman's sysupgrade operation.
Posted: Wed May 06, 2009 8:40 am
by deba5er
@ragnarok2040 - Thanks. Easiest toolchain install ever :-)
Posted: Mon Aug 10, 2009 4:39 pm
by yoshi314
sorry for butting in like that, but can you still build the toolchain on archlinux?
i'm getting issues with final gcc pkgbuild, it breaks somewhere due to missing headers. i'll try posting build logs in a few hours.
the pkgbuilds i have use gcc-34 explictly, so that it's probably something else than compiler issue.
Posted: Fri Aug 28, 2009 4:24 pm
by ragnarok2040
Sorry that I didn't respond faster, my Arch install broke after doing a kernel update back in April which catalyst didn't support until just this month.
I just did a total reinstall and didn't have any trouble except for having to build gcc34 from the AUR. Herben made some updated ps2toolchain patches so the toolchain should compile with newer versions of gcc, so gcc34 might not be needed anymore. I didn't see them until after I'd installed my toolchain, though.
Posted: Sun Aug 30, 2009 3:56 am
by dlanor
ragnarok2040 wrote:I just did a total reinstall and didn't have any trouble except for having to build gcc34 from the AUR. Herben made some updated ps2toolchain patches so the toolchain should compile with newer versions of gcc, so gcc34 might not be needed anymore. I didn't see them until after I'd installed my toolchain, though.
That's interesting. Does this also mean that there is now a better chance of using the toolchain with a modern Cygwin version ?
I need to keep Windows as my main OS for various reasons and MinGW is not sufficiently Linux-like to allow advanced scripts to work right, so I've been using an ancient Cygwin version for a long time now. This does work well for most things, but is hell to try upgrading parts of, since the new Cygwin packages are not compatible to the old stuff, which has also made use of the old PS2 toolchains impossible with new Cygwin setups. And this was mainly due to the GCC incompatibilities, if I understood those problems correctly.
Perhaps someone should check if it is now possible to build a new complete PS2 toolchain package that works with the current Cygwin stuff.
Best regards: dlanor
Posted: Sun Aug 30, 2009 3:14 pm
by ragnarok2040
From the changelog, it looks like a buffer overflow for ee-ar was fixed by compiling binutils with -O0. I wonder if that might fix the bug with ee-as which was the problem I ran into when compiling a 64-bit version of the toolchain. GCC was patched to fix collect2, which doesn't seem to relate to the Cygwin error, but I might have a fix for that.
In schedule_block() in haifa-sched.c, last_clock_var is initialized as 0 while clock_var is initialized as -1. Since clock_var is immediately incremented to 0, they become equal, which might be a problem. This doesn't really change the behavior all that much, so ready.n_ready could still return 0...
Code: Select all
diff -burN gcc-3.2.2-old/gcc/haifa-sched.c gcc-3.2.2/gcc/haifa-sched.c
--- gcc-3.2.2-old/gcc/haifa-sched.c 2009-08-30 01:00:15.198787402 -0400
+++ gcc-3.2.2/gcc/haifa-sched.c 2009-08-30 00:58:27.000000000 -0400
@@ -1641,6 +1641,7 @@
{
struct ready_list ready;
int can_issue_more;
+ int advance, start_clock_var;
/* Head/tail info for this block. */
rtx prev_head = current_sched_info->prev_head;
@@ -1693,15 +1694,19 @@
queue. */
q_ptr = 0;
q_size = 0;
- last_clock_var = 0;
+ last_clock_var = -1;
memset ((char *) insn_queue, 0, sizeof (insn_queue));
/* Start just before the beginning of time. */
clock_var = -1;
+ advance = 0;
/* Loop until all the insns in BB are scheduled. */
while ((*current_sched_info->schedule_more_p) ())
{
+ do
+ {
+ start_clock_var = clock_var;
clock_var++;
/* Add to the ready list all pending insns that can be issued now.
@@ -1718,6 +1723,9 @@
fprintf (sched_dump, ";;\t\tReady list after queue_to_ready: ");
debug_ready_list (&ready);
}
+ advance -= clock_var - start_clock_var;
+ }
+ while (advance > 0);
/* Sort the ready list based on priority. */
ready_sort (&ready);
Edit:I'm not sure if the bootstrap compiler or the cross-compiler needs to be patched with this... since the error seems to lack information on that. I'm guessing since it's erring out on building libstdc++ that xgcc has already been built and the internal compiler error is occurring in it. The cross-compiler works fine with the patch, from what I've tested so far.
Posted: Sun Aug 30, 2009 11:39 pm
by Herben
The changes I made allowed me to build the toolchain with gcc 4.3.3, binutils 2.19.1 on Ubuntu 9.04. I haven't tested it very much though so who knows what kind of funky codegen bugs might pop up. ps2sdk did compile fine though so maybe it works.. ;)
I pretty much hate GCC and friends. The theory of an all-in-one (x-)compiler and such is cool but I find it difficult to actually work with for "non-standard" things. I haven't been involved in ps2dev for a couple years now so maybe the bugs in the EE toolchain are sorted now but I remember some truly evil codegen bugs that popped up and cost a fair bit of time/energy to track down. And that only resulted in me figuring out what it was fucking up in my code, not the actual bug in the toolchain which causes it. So at best I could do stuff like turn off optimisations, align all my data to 16 bytes or simply implement stuff in assembler then link it in separately.. :P Not my idea of a good time!
I am grateful to the guys that have made the PS2 patches, though. I tried making patches to target PS1 EXE files based on some old ps1dev patches but eventually gave up on that due to the general cluster-fuck layout of GCC/binutils source followed by the same types of buffer-overflow/etc errors I tend to have when building the PS2 toolchain. I've got nothing but respect for those who can patch that beast into even the slightest semblance of functionality. ;)
Btw, I dig your FCEUMM port ragnarok. I use it to pacify my gf's kid on a regular basis. :D
Posted: Mon Aug 31, 2009 3:52 pm
by ragnarok2040
Hey, Herben, :D. Would that be 64-bit or 32?
I think a lot of the bugs are sorted out now except for
http://forums.ps2dev.org/viewtopic.php?t=1431
Yeah, I'm grateful for those patches, too, especially considering they had to modify the generic MIPS code already there, *_*.
:D, yeah, I use FCEUMM for my little brother since he loves robots, megaman in particular. I plan on updating it with some fixes but I've been working on an ERL/ELF loader/dashboard type app to simplify porting other emulators/software then doing a re-port of FCEUMM & Snes9x to that. The re-porting shouldn't take too long, it's just been a long time laying the groundwork.
Posted: Wed Sep 09, 2009 5:58 pm
by Herben
It's 32-bit.
Yeah, that's an example of the kind of bug I was talking about. Rarely does one need to work with 128-bit values but if ya do...
I know others have mentioned making an "emulator framework" in the past. You'd be the first to actually do it. ;) Using ERL should make things a bit cleaner. And it'd be nice to finally see ERL used in something! :D
Posted: Sun Sep 13, 2009 5:38 am
by ragnarok2040
Thanks. I haven't had time to test a 64-bit build to see if the optimization flags fixed ee-as, yet, but I'll get on that as soon as possible.
I've been examining that bug, but I'm not sure what's happening. If foo() is changed to signed, gcc moves it to $v1 then dsra32's it 63 bits then stores that value in $v0... which right shifts it to oblivion. Doing a unsigned TImode var = DImode var assignment doesn't work, either. TImode var = SImode var works, though. Defining foo() as SImode doesn't work. I probably uncovered another bug with DImode vars when I went looking :S.
:D, Yeah, right now it's still preliminary. I originally tried to use gsKit, but it's kind of heavy for an ERL launcher. Then I tried libgs, which I liked, but it's not that flexible for handling advanced GS features. Right now, I'm working on more complete versions of libdma, libdraw, libgraph, and libpacket based on what I've learned from reading pcsx2's, libgs's, and gsKit's sources as well as removing the interdepencies between them to simplify things. Should be pretty nice after I'm done, just a lot of groundwork, heh.
Posted: Tue Sep 15, 2009 1:57 am
by yoshi314
i've started making gentoo ebuilds for the toolchain. so far i made the binutils one. i don't think we need to install man pages with it. or do we?
btw,
find . -type d -name .svn -exec rm -rf "{}" \;
isn't it just better to do "svn export" from svn url/svn checkout dir?
http://github.com/yoshi314/yoshi314-overlay ; under "dev-embedded" category.
Posted: Tue Sep 15, 2009 5:52 am
by ragnarok2040
They're not really neccessary if you aren't planning on using some little known gcc option or etc. and googling for the behavior you want binutils/gcc to have rather than searching through the man pages is easier. Just keep in mind that they're more accurate for gcc-3.2.2 than gcc4's or gcc34's manpages are.
isn't it just better to do "svn export" from svn url/svn checkout dir?
It would be for non-patched sources, like ps2sdk/gsKit, but for those that are patched, I think uncommitted changes would be exported, but unversioned files added by patches would not.
I'll make a new post in the patches section with step-by-step methods to fix libpng and libjpeg from their current revisions so a svn maintainer with some time can fix it properly. A svn diff patch isn't enough to fix it, heh, and patches don't work well with migrating/removing files. Then the pkgbuilds can be modified to svn export.
Posted: Tue Sep 15, 2009 5:04 pm
by yoshi314
so i guess they are useful, after all (i thought they are just a repetition of what is already in vanilla binutils/gcc)
so the right way to install those man pages would be to throw them into toolchain dir and add it to MANPATH, right?
Posted: Wed Sep 16, 2009 1:21 am
by ragnarok2040
I thought MANPATH was deprecated, since man-db has pretty much taken over man and automates the finding of manpages, using man_db.conf and PATH. It looks like Gentoo still uses man though, so yeah, you should probably do that. You could even lump them together under ps2dev/man or something. If any conflicts arise, just remember that binutils-2.14's versions of the man pages are probably newer.
Edit:
I modified my original post so it's more to the point and lists new changes and etc.