pkg build problem
superg opened this issue · 32 comments
Hi,
I was trying to build some project pkg's, builds fine, but after execution there is error 80010017.
From what I saw on the net, it's "Can't start Blu-Ray Game".
After I overridden pkg build rule with my custom one, error disappeared:
PKGDIR := pkg
%.pkg: %.self
rm $(PKGDIR)/USRDIR/EBOOT.BIN
rm $(PKGDIR)/PARAM.SFO
(I've simplified my custom rule not to recopy all of data files to another directory, as for my application, there is a lot of data files - so there should be ICON0.PNG and empty USRDIR directory inside pkg)
So I think, problem is somewhere inside default pkg build rule, or related utilities.
Seems taking the .elf in the build dir (the stripped and sprx linked one) doesn't work. As that's the only difference to the current rule in ppu_rules in the repository.
It seems, strip stripping some needed sections, after I replaced strip command with cp in ppu_rules %.self:
%.self: %.elf
@echo output ...
everything worked fine. It's good enough as temporary solution.
strip was b0rken, but it has been fixed now. :-)
Was strip broken due to the ld bug, which has been fixed now by you?
Mostly it was broken because of my over-simplistic fix for the ld problem (ld and strip use the same libbfd). :-)
That said, I think strip had some problems with tdata corner cases even before that, which should be fixed now due to the upstreams changes by Adan Modra which I integrated.
Oh okay! Seems to be the final fix now :) Btw. have you seen, he added a couple more changes regarding this problem?
http://lists.nongnu.org/archive/html/bug-binutils/2011-05/msg00183.html
Yes, I just saw those additional changes. I haven't yet managed to wrap my brain around exactly what they are fixing though. :-) We should probably switch to binutils 2.22 once it is out, to make sure we get all that upstreams goodness...
Yes, probably the best to switch to next revision, instead of trying to fill in the patches.
Another question at this point here: How did the discussion end about the host tripplet? I think it'd be really the best to move to something like "powerpc64-ps3-elf"?
I think @ooPo said he was going to try it out on a branch when he got some time, but I don't know if that has happened yet. ;-)
It is on my list of things to do, but I've had very little free time lately. :)
Take a look at my branch of ps3toolchain (https://github.com/ooPo/ps3toolchain), it builds all the ppu stuff as powerpc64-ps3-lv2 and adds symlinks to remain compatible. Seems to work fine.
Hm, I see that you now have to patch config.sub to recognize --lv2 instead. Is this specific to binutils and gdb for some reason, or do all config.sub need that patch? Because that would kind of defeat the purpose of the change...
Just binutils and gdb need the patch to recognize *-lv2. GCC didn't mind a *-elf binutils, but newlib wouldn't compile until I changed it to *-lv2. I added the patch to gdb to be consistent. Everything else should work fine with the symlinks.
Yeah, after some time working with ps3libraries I think it might be nice to do some work to get powerpc64-ps3-elf as target.
The main problem is that powerpc64--elf isn't supported in GCC. I had this problem way back when I first started putting the toolchain together. I ended up using powerpc64-unknown-none and it worked out at the time because everything was just named ppu-. However, if we're not going to name things with ppu-* then by the time we get to newlib it will be either trying to use powerpc64-ps3-elf-* for assembling or powerpc64-ps3-lv2-* for compiling. That doesn't work so well.
I'd welcome some help here because I've spent a lot of time banging my head on this part back then and I'm not looking forward to doing it again. :)
If you change "powerpc64--lv2" to "powerpc64-ps3-elf" in gcc/config.gcc then GCC will support powerpc64-ps3-elf.
Changed and updated on the branch. Newlib is now having problems:
make[5]: Entering directory `/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/newlib/libc/argz'
powerpc64-ps3-elf-gcc -B/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/newlib/ -isystem /home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/newlib/targ-include -isystem /home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/newlib/libc/include -B/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/libgloss/powerpc64 -L/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/libgloss/libnosys -L/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/libgloss/powerpc64 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I../../../../../newlib/libc/argz -mrelocatable-lib -mno-eabi -mstrict-align -DMISSING_SYSCALL_NAMES -fno-builtin -g -O2 -c -o lib_a-dummy.o `test -f 'dummy.c' || echo '../../../../../newlib/libc/argz/'`dummy.c
../../../../../newlib/libc/argz/dummy.c:1:0: error: -mrelocatable and -mcall-aixdesc are incompatible
Hm, the error is caused by -mrelocatable-lib, and the old ppu-gcc also complains about this option, so I guess the error is that newlib specifies it in the first place. Also, the command line does not have -DREENTRANT_SYSCALLS_PROVIDED etc, so I think it has just failed to pick up our config. Did you remember to change "powerpc64--lv2_" to "powerpc64-ps3-elf" in newlib/configure.host? (There is also a "_--lv2*" which should be changed to "-ps3-", but that one should not cause this problem.)
I've added those changes and pushed them to my forks. There's a new problem:
powerpc64-ps3-elf-gcc -B/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/newlib/ -isystem /home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/newlib/targ-include -isystem /home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/newlib/libc/include -B/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/libgloss/powerpc64 -L/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/build-ppu/powerpc64-ps3-elf/libgloss/libnosys -L/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/libgloss/powerpc64 -g -O2 -O2 -I. -I../../../../libgloss/libsysbase/.. -c -g -O2 ../../../../libgloss/libsysbase/sbrk.c
../../../../libgloss/libsysbase/sbrk.c:14:1: error: conflicting types for 'sbrk'
/home/danpeori/Coding/Console/PS3/oopo/ps3toolchain/build/newlib-1.19.0/newlib/libc/include/sys/unistd.h:147:9: note: previous declaration of 'sbrk' was here
Newlib seems to be picking up a folder that it shouldn't. I'll have more time later to poke around with it.
Looks like -DREENTRANT_SYSCALLS_PROVIDED is still missing; it shouldn't compile line 14 of sbrk.c AFAICT...
After a few more changes it looks like everything is working now. I've updated the code on my forks if you want to give it a try. I've also updated my fork of ps3libraries, removing a bunch of patches in the process.
Ok, I'll give it a spin on Thursday I think (it's a national holiday here, so I get the day off :)
Results so far: Everything compiles and links, but all programs seem to hang as soon as they get to a PRX call. Still investigating...
Ok, found what's different: ATTRIBUTE_PRXPTR pointers are now sign extended. With the old toolchain they are zero-extended. So it looks like it's gcc which needs one more tweak...
Ah-ha. The reason for the breakage isn't the change of triplet at all, but simply that your newly generated gcc patch does not contain the change made by @shagkur in ps3dev/ps3toolchain@5b06077 . Apparently this fix was only made in the patch, and not in the gcc repo, so when the patch was regenerated the change was lost.
@ooPo: I've added the POINTERS_EXTEND_UNSIGNED fix to master of ps3dev/gcc-4.5.2-PS3, so if you merge that and regenerate the patch everything should be hunky-dory.
Merged and regenerated, give it a go.
Yup, all good now. +1 for push.
Great work guys!
Just one small question: There's still ppu) in config.sub which transforms to powerpc64-unknonw-lv2. Shouldn't that transform to powerpc64-ps3-elf?
Any ppu) remaining in config.sub should simply be removed. Where did you find it?
in the gcc.patch - config.sub.
Yes, that can be removed. It's never used since gcc is not configured with --host=ppu anymore. Also, the addition of -lv2* to the list of OSes further down in config.sub can be removed too. In short, all changes to config.sub can be removed from the gcc patch. They don't do any harm, but they don't do any good either.
I've removed these entries and regenerated the patches.