The first working ps3toolchain release!

[ooPo]

Can you post the actual error message? It is usually a lot easier to help out when we can see that.

It sounds like you may be linking in libraries in the wrong order.

[sopordave]

Code: Select all

$ make
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o start.o start.S
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o hv.o hv.S
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o mmu.o mmu.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o time.o time.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o vuart.o vuart.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o sysmgr.o sysmgr.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o av.o av.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o flash.o flash.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o fb.o fb.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o font_8x8.o font_8x8.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o debug.o debug.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector    -c -o demo.o demo.c
ppu-gcc: -lm: linker input file unused because linking not done
ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -lm -ffreestanding -fno-stack-protector -static -nostdlib -Wl,-T,script.lds -o demo.elf start.o hv.o mmu.o time.o vuart.o sysmgr.o av.o flash.o fb.o font_8x8.o debug.o demo.o
fb.o:(.text+0x690): undefined reference to `abs'
fb.o:(.text+0x6a0): undefined reference to `abs'
fb.o:(.text+0x6b4): undefined reference to `abs'
fb.o:(.text+0x6c8): undefined reference to `abs'
collect2: ld returned 1 exit status
make: *** [demo.elf] Error 1

[ldesnogu]

A few things:
- abs is not in math.h/libm, it's part of libc
- try to move -lm at end of link command-line

[sopordave]

A few things:
- abs is not in math.h/libm, it's part of libc
- try to move -lm at end of link command-line

oh yeah :) I was originally using fabs() but moved to integers, not realizing the change in libraries. I realize that abs() would be __very__ easy to implement on my own, but I will need to figure out this linker business eventually anyway. So, I changed back to fabs in an attempt to use the math library. Still, link error:

Code: Select all

ppu-gcc -O -m64 -mregnames -mfull-toc -G0 -ffreestanding -fno-stack-protector -lm -static -nostdlib -Wl,-T,script.lds -o demo.elf start.o hv.o mmu.o time.o vuart.o sysmgr.o av.o flash.o fb.o font_8x8.o debug.o demo.o
fb.o:(.text+0x6fc): undefined reference to `fabs'
fb.o:(.text+0x710): undefined reference to `fabs'
fb.o:(.text+0x724): undefined reference to `fabs'
fb.o:(.text+0x74c): undefined reference to `fabs'
collect2: ld returned 1 exit status
make: *** [demo.elf] Error 1

[sopordave]

I feel silly. After looking in the lib folder, there is no libm.a.

But there is a 32-bit library in lib/32. Does anybody know the reason why there isn't a 64-bit libm, or is my installation just screwed up?

[ooPo]

You need to put the libraries at the end of the line.

The linker parses the command line and makes a list of what functions it needs as it adds each object file. When it reaches a library it will link only the functions it knows it needs. If you add more object files after the library it doesn't go back and add the missing functions - you get an undefined reference.

There is a way to tell the linker to add everything, but I don't remember how at the moment.

[jimparis]

Code: Select all

-Wl,--start-group -la -lb -lc -Wl,--end-group

causes it to search a,b,c, repeatedly until all symbols are resolved or no progress is being made.

[ooPo]

Code: Select all

--whole-archive             Include all objects from following archives

This should work too, but be sure to strip the binary afterwards if you want to get rid of unused code.

[mc]

stripping does not remove unused code, just symbol and debug information.

[ooPo]

...and that would be why the whole-archive option isn't used. :)

Good to know.

[Undertaker]

I need some help I installed the toolchain but it said cant find the directory John Rone when to execute the scripts, I have read the post and tried to rename John Rone to John_Rone but it doesnt allow me to do it.Can anyone please help.What am I missing here?.I am using Cygwin.

[mc]

@ooPo: --whole-archive is useful sometimes when you don't know
beforehand which code will be used, e.g. when you have a dynamic
plug-in system. I use it in the Dreamcast port of ScummVM.

[ooPo]

Is there a way to strip out the unused parts of the archive after it has been linked in?

[mc]

Linking fixes the address layout, so after that you can not move any code. So even
if you were able to remove unused functions, it would just leave "holes", not make
the memory footprint smaller.

There is an option "--gc-sections" to ld which allows unused sections to be removed
during linking (rather than after) though.

But normally you should be fine with just using archives normally, without
--whole-archive. Then the linker will pull in the parts you need and skip the rest.

[J.F.]

The readme in the ps3toolchain dir still says to get libmfr instead of libmpfr. Someone might want to alter that. :)

Thanks.

[J.F.]

Ran into the infamous "makeinfo" bug compiling newlib for the ps3.

Code: Select all

make[3]: Entering directory `/home/jlfenton/projects/ps3/ps3toolchain/build/newlib-1.15.0/build-ppu/etc'
/home/jlfenton/projects/ps3/ps3toolchain/build/newlib-1.15.0/missing makeinfo --split-size=5000000 --split-size=5000000 --no-split -I../../etc -o standards.info ../../etc/standards.texi
WARNING: `makeinfo' is missing on your system.  You should only need it if
         you modified a `.texi' or `.texinfo' file, or any other file
         indirectly affecting the aspect of the manual.  The spurious
         call might also be the consequence of using a buggy `make' (AIX,
         DU, IRIX).  You might want to install the `Texinfo' package or
         the `GNU make' package.  Grab either from any GNU archive site.
make[3]: *** [standards.info] Error 1

I know that was run into with the PSP toolchain at some point as well. Could whoever fixed that please alter the PS3 toolchain as well? Thanks.

EDIT: You can get by the above using the manual procedure for the PSP, but there's an even bigger problem in script 6 - ftp://sourceware.org/pub/gcc/snapshots/ ... 08.tar.bz2 no longer exists. I'm using this url instead:
http://gcc-uk.internet.bs/snapshots/4.3 ... 08.tar.bz2

EDIT: The SPU newlib fails the same way. So changes for makeinfo need to be done in two places for the ps3 toolchain.

One more edit!: After all that, I got the toolchain compiled and installed. Otheros-demo-1.1 compiles, but you need to change the makefile - change "objcopy" to "ppu-objcopy". Then it makes everything fine down to the otheros.bld. :)

[ooPo]

What are these makeinfo changes?

[J.F.]

I haven't checked the current PSP scripts/patches, but the manual procedure was to change "MAKEINFO = /some/god/awful/long/path/makeinfo" into "MAKEINFO = makeinfo" in the newlib makefile, make and make install newlib, then continue with the next script.

I assumed SOMETHING was done to clear that issue in the PSP toolchain script since no one has complained about it.

[ooPo]

http://www.nabble.com/Check-for-makeinf ... 72513.html

In newlib configure it is a test for makeinfo version larger than 4.4.
On my Fedora7 distro texinfo got updated to version 4.11, and then this
test failed.

In 1.15.0 ./configure.in line 2236 this reads:

if ${MAKEINFO} --version \
| egrep 'texinfo[^0-9]*([1-3][0-9]|4\.[4-9]|[5-9])' >/dev/null
2>&1; then
:
Changeing it to:
if ${MAKEINFO} --version \
| egrep 'texinfo[^0-9]*([1-3][0-9]|4\.[4-9]|[5-9]|4\.1[0-9])'
>/dev/null 2>&1; then
:
fixes the problem.

A fix was posted on Sep 17th for the problem you noted so a patch is
not needed in the repository. It will be in the next newlib snapshot.

Perhaps its time to upgrade the version of newlib used in the toolchain?

[J.F.]

ps3sdk and ps3link is still being worked on and no public release has been made.

Any info on ps3sdk? An update on the progress would be much appreciated. Thanks.

[ooPo]

I don't think it ever existed. :)

[J.F.]

Is there nothing at all? Even notes on dividing up the stuff into libs? I was looking into my own libs needed for a project, but I'd rather not reinvent the wheel if I didn't have to. Otherwise, I'll just do my own libs, and maybe they can help towards an sdk. :)

[ooPo]

Go right ahead, I'd assume that if there was anything really active someone would have spoken up by now. :)

[J.F.]

Well, sometimes folks take awhile to respond, so I'll work on my stuff, but keep an eye on the thread. If no one says otherwise by the time I have a few libs and examples ready, I'll post them here for feedback.

[steelblood_relic]

During the ppu-gcc setup, I noticed something that didn't seem right. There was some output text saying something like "Checking for big-endian..." and I'm pretty sure it said "no". Is there something I have to setup to get it to compile my programs for big-endian Cell, or will the endianness be correct?

Also(maybe this is already answered, but I didn't find it after a quick search): I basically want to compile my PPU/SPU programs on win32/x86 using cygwin and running like an OtherOS without Linux installed(based on OtherOS-demo), will I be able to embed my SPU-programs in my PPU-program, use PPU/SPU-specific instrucions for SIMD functionality, etc, using this toolchain(basically, everything I can do with the IBM Cell SDK)?

Thank you.

[J.F.]

That was probably checking the HOST. Remember that you're cross-compiling.

Also, there's really not much more (yet) than the compiler and a partial libc and libm. There's no facility for launching SPU code in the OTHEROS toolchain. You'd need to handle all that by hand. You'd need something like libspu2 for OTHEROS.

[steelblood_relic]

That was probably checking the HOST. Remember that you're cross-compiling.

Also, there's really not much more (yet) than the compiler and a partial libc and libm. There's no facility for launching SPU code in the OTHEROS toolchain. You'd need to handle all that by hand. You'd need something like libspu2 for OTHEROS.

Thank you, that's exactly what I wanted to know. Cheers.

[rapso]

if you get quite some annoying bug building the toolchain like warnings because the return type was ignored, and those warnings are threaded like errors, it's probably due to the newest version of gcc (4.4.1 or somethin). fixing all those tiny issues takes really lot of time, I gave up after 2h.

a simple workaround is to downgrade your gcc e.g.

Code: Select all

apt-get remove gcc g++
apt-get install gcc-4.2 g++-4.2
ln -s /usr/bin/gcc-4.2 /usr/bin/gcc
ln -s /usr/bin/g++-4.2 /usr/bin/g++

it should be simple to update to the latest version by apt-get install gcc g++

just in case someone else runs into those issues ;)