A Fresh New Toolchain+libs - Compiled On Demand!

[Mudi]

All I know is that with devkitpro's arm-linux-gcc it will accept ".\filename.c" (which VS2005 requires) as an input filename, but yours won't. It's possible that devkitpro only put it in the patch for windows builds, but it should be a really easy patch to make... I might be able to make the patch myself if I get the motivation in the near future

 

[GeminiDomino]

Is everything in this toolchain supposed to be available on the unit itself? Because I've run into no small amount of trouble with libjpeg, for example (that's not the only one).

 

[Mudi]

Is everything in this toolchain supposed to be available on the unit itself? Because I've run into no small amount of trouble with libjpeg, for example (that's not the only one).

​

Just make sure you compile it static...

 

[GeminiDomino]

Is everything in this toolchain supposed to be available on the unit itself? Because I've run into no small amount of trouble with libjpeg, for example (that's not the only one).

​

Just make sure you compile it static...

​

That was the first thing I tried, but it didn't help. My guess is that the app isn't calling anything in libjpeg, but the SDL is, and if the SDL didn't compile static to libjpeg, passing -static libjpeg to compile the app won't help.

At least, that's my (limited) experience. I'm still a newbie coder, though.

 

[bjimba]

That was the first thing I tried, but it didn't help. My guess is that the app isn't calling anything in libjpeg, but the SDL is, and if the SDL didn't compile static to libjpeg, passing -static libjpeg to compile the app won't help.

At least, that's my (limited) experience. I'm still a newbie coder, though.

Well, no, that's not right. Static vs. dynamic linking happens at link time for your app, not at compile time for the SDL libs. If you've got static SDL libraries (*.a files) and a static JPEG lib, and you link your app with -static, you shouldn't be dependent on anything else.

What sort of trouble are you having with the JPEG lib? Do you have any error messages you could post?

 

[GeminiDomino]

That was the first thing I tried, but it didn't help. My guess is that the app isn't calling anything in libjpeg, but the SDL is, and if the SDL didn't compile static to libjpeg, passing -static libjpeg to compile the app won't help.

At least, that's my (limited) experience. I'm still a newbie coder, though.

Well, no, that's not right. Static vs. dynamic linking happens at link time for your app, not at compile time for the SDL libs. If you've got static SDL libraries (*.a files) and a static JPEG lib, and you link your app with -static, you shouldn't be dependent on anything else.

What sort of trouble are you having with the JPEG lib? Do you have any error messages you could post?

​

Here's the relevant lines from the makefile:

CFLAGS = `sdl-config --prefix=/home/domino/work/gp2xdev --cflags` -DGP2X -D__ARM__ -I/home/domino/work/gp2xdev/include -I./src 

LFILGS = -L/home/domino/work/gp2xdev/lib -Wl,-rpath,/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -lpng -lpng12 -ljpeg

obj/%.o:        src/%.cpp
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

obj/%.o:        src/%.c
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@
        
obj/%.o:        src/%.S
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

The error I get:

./patchednes.gpe: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: Ny

 

[bjimba]

Here's the relevant lines from the makefile:

CFLAGS = `sdl-config --prefix=/home/domino/work/gp2xdev --cflags` -DGP2X -D__ARM__ -I/home/domino/work/gp2xdev/include -I./src 

LFILGS = -L/home/domino/work/gp2xdev/lib -Wl,-rpath,/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -lpng -lpng12 -ljpeg

obj/%.o:        src/%.cpp
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

obj/%.o:        src/%.c
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@
        
obj/%.o:        src/%.S
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

Well, first I think LFILGS is a typo. The standard name for linker flags is LDFLAGS.

Second, do you really mean -static-libgcc? You should have -static to do static linking. I don't know what -static-libgcc means.

Third, I was always under the impression that the LD_LIBRARY_PATH environment variable was only used at runtime of the app to find shared libraries. Why are you setting it in the Makefile?

 

[GeminiDomino]

Here's the relevant lines from the makefile:

CFLAGS = `sdl-config --prefix=/home/domino/work/gp2xdev --cflags` -DGP2X -D__ARM__ -I/home/domino/work/gp2xdev/include -I./src 

LFILGS = -L/home/domino/work/gp2xdev/lib -Wl,-rpath,/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -lpng -lpng12 -ljpeg

obj/%.o:        src/%.cpp
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

obj/%.o:        src/%.c
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@
        
obj/%.o:        src/%.S
        export LD_LIBRARY_PATH=/home/domino/work/gp2xdev/lib
        $(CC) -c $(CFLAGS) $< -o $@

Well, first I think LFILGS is a typo. The standard name for linker flags is LDFLAGS.

Second, do you really mean -static-libgcc? You should have -static to do static linking. I don't know what -static-libgcc means.

Third, I was always under the impression that the LD_LIBRARY_PATH environment variable was only used at runtime of the app to find shared libraries. Why are you setting it in the Makefile?

​

Bugger if I know. I didn't write the makefile, I've just been editing it because I changed 2 bytes in the source file and want to recompile.

The -static-libgcc was already there, I added -static -lpng -lpng12 -ljpeg ( the second -static didn't show up in the cut/paste. Damned pico. )

As for the LD_Library_path, man ld says the linker will obey it during linking, and it seems to work (without it, for some reason, it keeps trying to use my x86 SDL despite the -L)

 

[bjimba]

Bugger if I know. I didn't write the makefile, I've just been editing it because I changed 2 bytes in the source file and want to recompile.

The -static-libgcc was already there, I added -static -lpng -lpng12 -ljpeg ( the second -static didn't show up in the cut/paste. Damned pico. )

As for the LD_Library_path, man ld says the linker will obey it during linking, and it seems to work (without it, for some reason, it keeps trying to use my x86 SDL despite the -L)

Okay, given those clues, my guess is that the typo is killing you, and the linker is not getting its flags. Try LFLAGS instead of LFILGS, and if that doesn't work, try LDFLAGS.

 

[GeminiDomino]

Okay, given those clues, my guess is that the typo is killing you, and the linker is not getting its flags. Try LFLAGS instead of LFILGS, and if that doesn't work, try LDFLAGS.

​

No, I'm pretty sure that's not it. LFILGS is a variable, and it's spelled the same way in the only other line where it's called.

$(TARGET): $(OBJECTS)
        $(CC) -o $@ $(OBJECTS) $(LFILGS) -lm -lz

I've changed it anyway and rebuilt (gotta love SSH), but I won't be able to test it until I get home in the morning (I've got no way to get it onto an SD card at work.)

BTW, just for your edification:

From `man 1 gcc`

-shared-libgcc
-static-libgcc
On systems that provide libgcc as a shared library,
these options force the use of either the shared or
static version respectively. If no shared version of
libgcc was built when the compiler was configured,
these options have no effect.

 

[bjimba]

I've changed it anyway and rebuilt (gotta love SSH), but I won't be able to test it until I get home in the morning (I've got no way to get it onto an SD card at work.)

Well, I'm running out of ideas, then. Can you capture the output of a make run and see if your flags make it to the gcc link step? Also, look in /home/domino/work/gp2xdev/lib and make sure you have the static libs there (libSDL.a, libjpeg.a, etc.). I expect that by this point, I'm telling you things you've already done, but...

BTW, just for your edification:

From `man 1 gcc`

-shared-libgcc
-static-libgcc
On systems that provide libgcc as a shared library,
these options force the use of either the shared or
static version respectively. If no shared version of
libgcc was built when the compiler was configured,
these options have no effect.

​

Ah, thanks. I think for the ooPo toolchain, this will have no effect, as libgcc is only built static.

 

[GeminiDomino]

Well, I'm running out of ideas, then. Can you capture the output of a make run and see if your flags make it to the gcc link step? Also, look in /home/domino/work/gp2xdev/lib and make sure you have the static libs there (libSDL.a, libjpeg.a, etc.). I expect that by this point, I'm telling you things you've already done, but...

domino@thorr:~/work/gp2xdev/lib$ ls *.a
libSDL.a libSDL_mixer.a libfreetype.a libmikmod.a libsmpeg.a
libSDL_gfx.a libSDL_ttf.a libiberty.a libpng.a@ libz.a*
libSDL_image.a libSDLmain.a libjpeg.a libpng12.a

No problem there...

gp2x-gcc -o nesgp2x.gpe ./obj/InfoNES.o ./obj/InfoNES_Mapper.o ./obj/sdl/InfoNES_System_SDL.o ./obj/sdl/filer.o ./obj/ncpu.o ./obj/ncpu_io.o ./obj/apu/nes_apu.o -L/home/domino/work/gp2xdev/lib -Wl,-rpath,/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -static -lpng -lpng12 -ljpeg -lm -lz

Looks like that works.

EDIT: Or not... Now its failing on unicodefont for some reason. *rubs temples* Deep breaths...

EDIT Again:
Ok, I've got it. The problem seems to be that if I use -static, it wants to compile ALL of the libraries statically (which fails since libUnicodeFont doesn't build a static library). So the trick is to get LFLAGS to link SDL and Unicode dynamically (since I don't want the SDL compiled in for obvious reasons) and png, png12, and jpeg statically.

I tried the following:

LFLAGS = -L/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -Wl,-rpath,/home/domino/work/gp2xdev/lib,-Bstatic -lpng -lpng12 -ljpeg

But -Wl doesn't seem to want to take 2 options (-rpath and -Bstatic), and overrides the -rpath

/home/domino/work/gp2xdev/lib/gcc/gp2x/4.0.2/../../../../gp2x/bin/ld: warning: libz.so.1, needed by /home/domino/work/gp2xdev/lib/libSDL_image.so, not found (try using -rpath or -rpath-link)

The same thing happens if I use two seperate -Wl sequences.


EDIT yet again:

Ok, I found an lflags line which will allow compilation:

LFLAGS = -L/home/domino/work/gp2xdev/lib -lSDL -lstdc++ -lSDL_image -lunicodefont -lpthread -static-libgcc -Wl,-rpath,/home/domino/work/gp2xdev/lib -lpng -lpng12 -ljpeg -lz -lm -Wl,-Bstatic -lpng -ljpeg -lpng12

That still tries to link them dynamically. It's odd. If I try to link them statically, then I get errors because SDL_IMAGE needs to dynamically link to libjpeg, but libjpeg isn't on the gp2x. So how does it work there if the static vs. dynamic linking of the SDL isn't the issue?

I'm beginning to think I just need to give this up. Whatever toolchain the author used doesn't seem to be compatible with the libraries ooPo's toolchain has, for whatever reason.

 

[bjimba]

Ok, I've got it. The problem seems to be that if I use -static, it wants to compile ALL of the libraries statically (which fails since libUnicodeFont doesn't build a static library). So the trick is to get LFLAGS to link SDL and Unicode dynamically (since I don't want the SDL compiled in for obvious reasons) and png, png12, and jpeg statically.

Aha, now I see. You're in the nasty minefield of "I want some static and some dynamic". I think a lot of us have been avoiding this by linking EVERYTHING staticly, including SDL. For a system like the GP2X, it's really the most reasonable course. You don't want to depend on some particular version of SDL dynamic libraries to have been copied to the NAND.

You remember when I said that the "static vs. dynamic" decision was made at link time? Well, creating a dynamic library is in effect a linking process, so the dynamic SDL_image.so has already decided that libjpeg should be dynamic. That's why you can't control that decision during your app's link step.

Your simplest solution, then, may be to include the dynamic libjpeg.so as part of your app's directory when you copy it to the SD, and include an LD_LIBRARY_PATH statement in the .gpe that starts the app up.

 

[GeminiDomino]

Ok, I've got it. The problem seems to be that if I use -static, it wants to compile ALL of the libraries statically (which fails since libUnicodeFont doesn't build a static library). So the trick is to get LFLAGS to link SDL and Unicode dynamically (since I don't want the SDL compiled in for obvious reasons) and png, png12, and jpeg statically.

Aha, now I see. You're in the nasty minefield of "I want some static and some dynamic". I think a lot of us have been avoiding this by linking EVERYTHING staticly, including SDL. For a system like the GP2X, it's really the most reasonable course. You don't want to depend on some particular version of SDL dynamic libraries to have been copied to the NAND.

You remember when I said that the "static vs. dynamic" decision was made at link time? Well, creating a dynamic library is in effect a linking process, so the dynamic SDL_image.so has already decided that libjpeg should be dynamic. That's why you can't control that decision during your app's link step.

Your simplest solution, then, may be to include the dynamic libjpeg.so as part of your app's directory when you copy it to the SD, and include an LD_LIBRARY_PATH statement in the .gpe that starts the app up.

​

Yeah, I figured it was something like that. It's got to be a toolchain thing, though, because the original didn't have the libjpeg. *shrug*

It's not really that important since without savestates, I don't have the time (or battery life) to play through the real GOOD NES games anyway.

 

[Uncanny]

You sure know that the firm 1.4.0 plays the audio very fast, like "smurf sound" :lol:

In the last version of this toolchain build script, in lib SDL_mixer build with firm 1.4, the audio plays at normal speed? :unsure:

 

[ooPo]

Are you saying it runs at normal speed for you?

 

[Uncanny]

Are you saying it runs at normal speed for you?

​

First, your script it's a great work! thx ooPo

No, it runs very fast. I'm using a toolchain that I builded a few weeks ago (the first o second version) with an older versión of your script (but when I build it, I changed it to use Tremor with SDL_mixer thanks to the theoddbot's patch) and all it's OK when compiled things, for example the SDL Test of Guyfawkes runs perfectly (sound included of course) but after the upgrade to the firm 1.4 with the same compiled SDL Test the plays audio very fast (OGG, WAV or tracker modules, just the same speed).

Guyfawkes compiled the SDL libs (SDL_mixer included) that fix the audio, but he said that was build with a previous version of your toolchain, but I don't know if your last toolchain script fix this issue too :unsure:

And thanks for your rapid reply

P.D. Sorry about my english

 

[ooPo]

I have the same problem. Sound plays way too fast in firmware v1.4, but I haven't looked into fixing it yet as I've been busy with other things. Does anyone else have a fix yet?

 

[Uncanny]

Umm, about the fast audio speed issue I believe that I have finded the "what", but not the "why" yet. It's only the Guyfawkes's mikmod precompiled library, I don't understand why it's different, because Guyfawkes says in other thread that he changed nothing in your script, but his libmikmod it's work perfectly in the firm 1.4.0 and previous firms too... :huh:

Try it, just use o recompile the libs with you toolchain and copy the Guyfawkes's mikmod library and compile any test sound program (Guyfawkes SDL Test for example) the audio sounds fine, WAV, OGG or MOD... now the question is "why" :unsure:

For answer his question I ask in this thread to Guyfawkes a few questions.

 

[CRP]

I just tried the toolchain on OSX, but it gives an error upon compiling binutils:

gcc -g -O2 -c -o flat_bl.o ../../gprof/flat_bl.m
../../gprof/flat_bl.m:2: error: parse error before '%' token
make[3]: *** [flat_bl.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-gprof] Error 2


any idea?