Linux Toolchain Help


Enverex said:
That seems a little strange, I thought the point of SDL was portability? It's not very portable if it contains x86 ASM and so wont compile for other platforms without modification, lol (it's actually SDL I was trying to compile here, not a program...)
Click to expand...

Hmm, then if it is x86 asm it must be possible to remove. What does your configure look like?
 
Last edited by a moderator:
Configure is:

Code: 
#!/bin/sh

PREFIX=$PNDSDK
HOST=arm-none-linux-gnueabi
TARGET=arm-none-linux-gnueabi

export PREFIX
export HOST
export TARGET

PATH=$PATH:$PREFIX/bin
export PATH

./configure --prefix=$PREFIX --with-sdl-exec-prefix=$PREFIX --host=$HOST --target=$TARGET --build=`uname -m` CPPFLAGS="-I$PREFIX/include" CXXFLAGS="-fomit-frame-pointer" LDFLAGS="-L$PREFIX/lib" --disable-core-inline

(or did you mean the actual configure file?)
Pretty much the same as yours. When you compiled the SDL libs for your toolchain did you run into any similar issues?
 
Thats what I meant. Remove the
--disable-core-inline
It only applies to dosbox.

Here is an example from the open2x libs, of course the enable-video-gp2x doesnt apply. But this should give the idea. do a ./configure --help to see all the options.
Code: 
        $(FLAGS) ./configure --prefix=$(PREFIX)\
                --target=$(TARGET)\
                --host=$(HOST)\
                --build=$(BUILD)\
                --oldincludedir=$(PREFIX)/arm-open2x-linux/include\
                --enable-shared\
                --enable-static\
                --enable-pthreads\
                --enable-pthreads-sem\
                --enable-threads\
                --disable-video-directfb\
                --disable-video-x11\
                --disable-arts\
                --disable-esd\
                --enable-video\
                --enable-video-gp2x
 
Last edited by a moderator:
Ah right, I left that in before as I thought it was part of what the ARM processor in the Pandora does/doesn't support. Thanks, I'll fiddle about now.
 
Spent a while trying to understand it all and I think I'm progressing, decided to have a play-about with it again tonight but running into a few more issues:

Trying to compile UADE still results in:
Code: 
defiant uade-2.12 # armmake
/usr/bin/gmake -C src
gmake[1]: Entering directory `/home/ben/arm-source/uade-2.12/src'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/ben/arm-source/uade-2.12/src'
/usr/bin/gmake -C src/frontends/uade123
gmake[1]: Entering directory `/home/ben/arm-source/uade-2.12/src/frontends/uade123'
/usr/local/pandora/arm-2007q3/bin/arm-none-linux-gnueabi-gcc -Wall -O2 -I../../include -I../common -I/usr/local/pandora/arm-2007q3/include --static -g  -L/usr/local/pandora/arm-2007q3/lib -o uade123 uade123.o chrarray.o playlist.o playloop.o audio.o terminal.o unixatomic.o uadeipc.o amifilemagic.o eagleplayer.o unixwalkdir.o effects.o uadecontrol.o uadeconf.o md5.o ossupport.o songdb.o songinfo.o vplist.o support.o -lao -L/usr/local/pandora/arm-2007q3/lib --static  -L/usr/local/pandora/arm-2007q3/lib -lm
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o): In function `ao_shutdown':
audio_out.c:(.text+0x618): undefined reference to `dlclose'
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o): In function `ao_initialize':
audio_out.c:(.text+0x8fc): undefined reference to `dlopen'
audio_out.c:(.text+0x93c): undefined reference to `dlsym'
audio_out.c:(.text+0x95c): undefined reference to `dlsym'
audio_out.c:(.text+0x97c): undefined reference to `dlsym'
audio_out.c:(.text+0x99c): undefined reference to `dlsym'
audio_out.c:(.text+0x9bc): undefined reference to `dlsym'
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o):audio_out.c:(.text+0x9dc): more undefined references to `dlsym' follow
collect2: ld returned 1 exit status
gmake[1]: *** [uade123] Error 1
gmake[1]: Leaving directory `/home/ben/arm-source/uade-2.12/src/frontends/uade123'
make: *** [uade123] Error 2

My configure script is as follows:
Code: 
#!/bin/sh

PREFIX=$PNDSDK
HOST=arm-none-linux-gnueabi
TARGET=arm-none-linux-gnueabi

export PREFIX
export HOST
export TARGET

PATH=$PATH:$PREFIX/bin
export PATH

CPPFLAGS="-I$PREFIX/include" CXXFLAGS="-fomit-frame-pointer" LDFLAGS="-L$PREFIX/lib" LD_LIBRARY_PATH="-L$PREFIX/lib" \
     PKG_CONFIG_PATH="-L$PREFIX/lib/pkgconfig" CFLAGS="-L$PREFIX/lib" \
     ./configure --prefix=$PREFIX --host=$HOST --target=$TARGET --build=`uname -m` --enable-static \
     --target-cc=$PNDSDK/bin/arm-none-linux-gnueabi-gcc --without-audacious --without-uadefs

I have the BLAH="" vars outside of the configure as they seem to work better that way for some reason. Looks like an issue with libao but honestly not sure what.

And for reference:
Code: 
defiant uade-2.12 # file /usr/local/pandora/arm-2007q3/lib/libao.a
/usr/local/pandora/arm-2007q3/lib/libao.a: current ar archive
defiant uade-2.12 # file /usr/local/pandora/arm-2007q3/lib/libao.so
/usr/local/pandora/arm-2007q3/lib/libao.so: symbolic link to `libao.so.2.1.3'
defiant uade-2.12 # file /usr/local/pandora/arm-2007q3/lib/libao.so.2.1.3 
/usr/local/pandora/arm-2007q3/lib/libao.so.2.1.3: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
 
Ignore that, it was a static library issue, fixed it and compiled successfully:

defiant uade-2.12 # file /usr/local/pandora/arm-2007q3/bin/uade*
/usr/local/pandora/arm-2007q3/bin/uade123: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

Hooray. Now to make it static... --enable-static doesn't seem to work. Any ideas? (not sure if it's complicated or simple to do, Google says I just need "--enable-static" in configure but it's never that simple).
 
Enverex said:
Ignore that, it was a static library issue, fixed it and compiled successfully:

defiant uade-2.12 # file /usr/local/pandora/arm-2007q3/bin/uade*
/usr/local/pandora/arm-2007q3/bin/uade123: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped

Hooray. Now to make it static... --enable-static doesn't seem to work. Any ideas? (not sure if it's complicated or simple to do, Google says I just need "--enable-static" in configure but it's never that simple).
Click to expand...

uade is the application right, not a library why would you want it to be static. Or are you refering to libao?

Edit: maybe you mean compile the application uade with static linking? In this case just add -static to your linker flags
 
Last edited by a moderator:
To make libao linked statically, remove the -lao line and replace it with the absolute path to libao.a. That should link it in statically as opposed to dynamically. I think the issue with using --enable-static or -static is that it causes the executable to be TOTALLY statically linked - it avoids all shared libraries.
 
I assume he's trying to make it PND satisfactory. Any libs not included in the firmware should be statically linked in if it's to be packaged well inside a PND. I suppose the libs in question could also be packaged in with the executable in the PND though..
 
Vorporeal said:
I assume he's trying to make it PND satisfactory. Any libs not included in the firmware should be statically linked in if it's to be packaged well inside a PND. I suppose the libs in question could also be packaged in with the executable in the PND though..
Click to expand...

Completely forgot I could do that.

I'm referring to making UADE static, not libao btw, making libao static wouldn't really make much sense. Making UADE static was more for simplicity than anything else. Looks like I'm confusing the meaning of static libraries, from what I read up before I assumed it built the libraries code into the executable itself so that you didn't need additional files, that's obviously not the case now though.

Let me bundle it up to see if anyone can test it...

No wait, I was right - http://wiki.linuxquestions.org/wiki/Static_linking - so basically if I want UADE to be statically linked, how would I do so? Would -static in the -L line be enough as Pickle said? I think I tried that and it failed horribly (wouldn't compile). Let me try again...
 
Last edited by a moderator:
Yeah, looks like it bails when I try and statically link it:

Code: 
/usr/bin/gmake -C src
gmake[1]: Entering directory `/home/ben/arm-source/uade-2.12/src'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/ben/arm-source/uade-2.12/src'
/usr/bin/gmake -C src/frontends/uade123
gmake[1]: Entering directory `/home/ben/arm-source/uade-2.12/src/frontends/uade123'
/usr/local/pandora/arm-2007q3/bin/arm-none-linux-gnueabi-gcc -Wall -O2 -I../../include -I../common -I/usr/local/pandora/arm-2007q3/include -g  -L/usr/local/pandora/arm-2007q3/lib -L/usr/local/pandora/arm-2007q3/usr/lib -static -o uade123 uade123.o chrarray.o playlist.o playloop.o audio.o terminal.o unixatomic.o uadeipc.o amifilemagic.o eagleplayer.o unixwalkdir.o effects.o uadecontrol.o uadeconf.o md5.o ossupport.o songdb.o songinfo.o vplist.o support.o -lao -L/usr/local/pandora/arm-2007q3/lib  -Wl,--rpath -Wl,LIBDIR -L/usr/local/pandora/arm-2007q3/lib -L/usr/local/pandora/arm-2007q3/usr/lib -static -lm
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o): In function `ao_shutdown':
audio_out.c:(.text+0x618): undefined reference to `dlclose'
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o): In function `ao_initialize':
audio_out.c:(.text+0x8fc): undefined reference to `dlopen'
audio_out.c:(.text+0x93c): undefined reference to `dlsym'
audio_out.c:(.text+0x95c): undefined reference to `dlsym'
audio_out.c:(.text+0x97c): undefined reference to `dlsym'
audio_out.c:(.text+0x99c): undefined reference to `dlsym'
audio_out.c:(.text+0x9bc): undefined reference to `dlsym'
/usr/local/pandora/arm-2007q3/lib/libao.a(audio_out.o):audio_out.c:(.text+0x9dc): more undefined references to `dlsym' follow
collect2: ld returned 1 exit status
gmake[1]: *** [uade123] Error 1
gmake[1]: Leaving directory `/home/ben/arm-source/uade-2.12/src/frontends/uade123'
make: *** [uade123] Error 2

Works fine normally, but if I add "-static" to the LD and CFLAGs then it fails with the above message. Are you statically linking everything Pickle, or are you leaving everything as dynamic?
 
Enverex said:
Yeah, looks like it bails when I try and statically link it:

Works fine normally, but if I add "-static" to the LD and CFLAGs then it fails with the above message. Are you statically linking everything Pickle, or are you leaving everything as dynamic?
Click to expand...

trying adding -ldl
But most everyone including me is going to be compiling dynamically. The only reason you would really want to compile statically is if you need to a particular library in your software. The best example was with the gp2x, everyone compiled statically since we wanted to use the community HW Accelerated SDL, not the GPH dynamic linked SDL.
 
Last edited by a moderator:
Ah, no worries then. I've got everything compiling happily that uses auto-tools and also anything that uses CMake too (thought that would be more effort than it was for cmake but it was pretty simple). Using -ldl did work for static but if you say dynamic then I'll go with dynamic :)
 
One last question. Say I have an app that I want to run on the Pandora and I've cross-compiled it on my desktop. What is the best way to then run this on the Pandora? I could copy the folder over and run it from the folder (will this actually work with everything?), but then I've got all the cruft of the source files in there too. In addition, what about apps that need extra libraries at runtime? (which I'm certain many will).
 
Enverex said:
One last question. Say I have an app that I want to run on the Pandora and I've cross-compiled it on my desktop. What is the best way to then run this on the Pandora? I could copy the folder over and run it from the folder (will this actually work with everything?), but then I've got all the cruft of the source files in there too. In addition, what about apps that need extra libraries at runtime? (which I'm certain many will).
Click to expand...

running on pandora is not different than how you run anything on a pc, you copy over the binary and/or data files. You can also copy extra libraries to library folder.
 
Last edited by a moderator:
Pickle said:
Enverex said:
One last question. Say I have an app that I want to run on the Pandora and I've cross-compiled it on my desktop. What is the best way to then run this on the Pandora? I could copy the folder over and run it from the folder (will this actually work with everything?), but then I've got all the cruft of the source files in there too. In addition, what about apps that need extra libraries at runtime? (which I'm certain many will).
Click to expand...

running on pandora is not different than how you run anything on a pc, you copy over the binary and/or data files. You can also copy extra libraries to library folder.
Click to expand...

That much I know, it's the "people shouldn't really put anything on the NAND" and the fact there isn't that much space on the NAND to put files that worries me. I suppose I could always just put a bin and libs folder on an SD card and add those to PATH.

Basically I'm just wondering how you'd "install" them, without using up all your NAND space. Assuming I don't install too many libraries that should be ok, but do you have another plan, personally Pickle?
 
Last edited by a moderator:
Enverex said:
Pickle said:
Enverex said:
One last question. Say I have an app that I want to run on the Pandora and I've cross-compiled it on my desktop. What is the best way to then run this on the Pandora? I could copy the folder over and run it from the folder (will this actually work with everything?), but then I've got all the cruft of the source files in there too. In addition, what about apps that need extra libraries at runtime? (which I'm certain many will).
Click to expand...

running on pandora is not different than how you run anything on a pc, you copy over the binary and/or data files. You can also copy extra libraries to library folder.
Click to expand...

That much I know, it's the "people shouldn't really put anything on the NAND" and the fact there isn't that much space on the NAND to put files that worries me. I suppose I could always just put a bin and libs folder on an SD card and add those to PATH.

Basically I'm just wondering how you'd "install" them, without using up all your NAND space. Assuming I don't install too many libraries that should be ok, but do you have another plan, personally Pickle?
Click to expand...

Well modifying the LD path has been one idea being floated around. But to be honest we have 512 mb of nand, its not going to be taken up by adding shared libraries.
The best solution I think would be a process that would get the shared libraries added into the image so everyone gets the libraries.
 
Last edited by a moderator:
Pickle said:
Well modifying the LD path has been one idea being floated around. But to be honest we have 512 mb of nand, its not going to be taken up by adding shared libraries.
The best solution I think would be a process that would get the shared libraries added into the image so everyone gets the libraries.
Click to expand...
Are you sure it's wise to do that? .so libs are not that small; add a few different versions of any of each needed lib and your 512MB might very well be full much earlier than you'd expect.
 
Last edited by a moderator:
Admittedly UnionFS seemed like a good idea. Not a simple as just using the NAND, but it allows you to technically use the root FS without using the NAND space... (also solves the "home on the NAND" issue too).
 
You must log in or register to reply here.

Similar threads

P
Toolchain Problems...
Replies
7
Views
5K
sindbad
S
chris_c
Legallity Of Distributing A Toolchain
Replies
1
Views
704
sebt3
sebt3
M
Compiling Issues With Code::blocks On Windows
Replies
18
Views
6K
sdm
S
slygamer
GP2X Building Open2x Toolchain To Run On Gp2x
Replies
1
Views
2K
aapje89
A
H
Building A Native Toolchain
Replies
4
Views
3K
hmn
H
Back
Top