Linux Toolchain Help

[Pickle]

I was trying to use CodeSorcerery and such but honestly couldn't get my head around it (I'm probably missing something obvious but I learn best by example). Does anyone have any laymen's guides for this? I'm sure i'll pick it up quickly but getting started is always the hard part.

I got ARM Debian working in QEMU well, but compiling was so painfully slow that a basic app (a tiny little thing) took over an hour to compile which isn't good and has put me off compiling anything larger via that method (which is a shame because it was ideal really, no cross-compiling nonsense).

what are you trying to compile?

 

[Enverex]

I was trying to use CodeSorcerery and such but honestly couldn't get my head around it (I'm probably missing something obvious but I learn best by example). Does anyone have any laymen's guides for this? I'm sure i'll pick it up quickly but getting started is always the hard part.

I got ARM Debian working in QEMU well, but compiling was so painfully slow that a basic app (a tiny little thing) took over an hour to compile which isn't good and has put me off compiling anything larger via that method (which is a shame because it was ideal really, no cross-compiling nonsense).

what are you trying to compile?

I was trying to set up a generic environment that would work for most things (of course that wont work globally as mentioned some apps use different compile methods).

One I was trying was UADE - http://zakalwe.fi/uade
Another was Widelands - http://wl.widelands.org/

I was just basically checking to see if these apps compile for ARM first and foremost, just working my way through programs that I thought would run without modification to their original code (due to screen sizing issues, etc).

 

[Pickle]

You picked a good one
UADE is tricky it needs both a target compiler and a native compiler. In this case our native is the i686 gcc and the target is the ARM gcc. I used a configure script from like the example I posted previously. But rather than bother figuring out how the configure works to do this automatically, I simply went to the makefile in the src directory and changed:

CC = /opt/toolchains/pandora/2007q3-51/bin/arm-none-linux-gnueabi-gcc
 NATIVECC = gcc

To explain why the need for 2 compilers, UADE apparently need to run a tool during the build process (build68k), but it builds this tool during the make process. Since the tool has to be run on the host platform it needs to be in x86, not ARM. So it needs to be compiled with the native compiler (NATIVECC). The final binary needs be in ARM format so it uses the target compiles (CC).

Make sense?

 

[Enverex]

Makes complete sense, it's just not something I had even considered may have been happening
Another issue I ran into is when trying to compile some things, they require say, SDL already installed. I cross-compiled that to my fake Pandora folder, but then of course I can't just package up the installed files as for some reason the configure process seemed to require the SDL files to be present under the $PREFIX folder (I thought PREFIX just specified where to install to?). It's probably something stupid I'm missing again...

I'm obviously still doing something wrong though. Even after adding in your additional makefile changes, it still produces:
ben@defiant ~/arm-source/uade-2.12 $ file /usr/local/pandoraroot/bin/uade123
/usr/local/pandoraroot/bin/uade123: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Ok, I think this cross-compiling malarky is getting the better of me. I'll just wait until I get my Pandora and compile the apps directly on the device itself. One thing I will need to figure out at that point though is how to package them up for other people. Do we have a set way of doing that yet? (I'm familiar with making debs, arch AUR and ebuilds but I'm not sure what's been settled on for the Pandora's distro yet).

 

[Pickle]

I'm obviously still doing something wrong though. Even after adding in your additional makefile changes, it still produces:
ben@defiant ~/arm-source/uade-2.12 $ file /usr/local/pandoraroot/bin/uade123
/usr/local/pandoraroot/bin/uade123: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

Theres another makefile for uade123 frontend did you change the CC compiler there to point to the ARM cross compilier? Looks like your still using your 64 bit x86 compilier.
Check uadecore: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped

 

[Enverex]

Nope, missed it. :/

Can I not just set global system variables to the arm equiv. So that you don't have to manually edit lots of make files and it would make things much quicker and less fiddly.

 

[Pickle]

Add --target-cc to your configure script or statement and add the path to the ARM complier like this:
--target-cc=$PREFIX/bin/$TARGET-gcc

Now the frontend wants to use libao, so I had to get that compile it and add the libs and headers to my lib and include. Also the configure script trys be smart and looks for pkg-config, which I dont have in my toolchain. So I changed the configure script:

if test "$useuade123" = "yes" ; then
    AOFLAGS=""
    AOLIBS="-lao -L$prefix/lib"
    AOFLAGS="-I$prefix/include"
#    if test -n "$PKG_CONFIG" ; then
#    AOFLAGS=$($PKG_CONFIG --cflags ao)
#    if test "$?" != "0"; then
#        echo ""
#        echo "Can not compile uade123. Please install libao (including development kit)."
#        echo ""
#        useuade123="no"
#    fi
#    AOLIBS=$($PKG_CONFIG --libs ao)
#    fi
fi

Its up to you can you do it like I did or you can create/modify the pkg-config. If you use pkg-config, you might have to use --pkg-config to point to the correct path.
But that let me configure and compile the uaecore and uae123 without touching any makefiles.

 

[Enverex]

Great, one last silly question, how do you then get -just- the compiled app (and or libs) separate to the source or prefix to then upload? (Without having to manually go and try and find each one from where it's been installed).

I'm sure there is an easy way to do it but I can't remember the syntax.

 

[javaJake]

./configure --prefix is what you want. You're going to want to use two separate "prefixes", then: one for your toolchain and one for your installation. (The only issue with that, is it isn't exactly portable. This is where statically vs. dynamically compiled libraries come in.)

Just a query on this though, I don't intend to use Gentoo on my Pandora, I intend to use whatever the closest thing to an official distro is (I want to go with max compatability here) so I'm purely looking at compiling for ARM, not installing Gentoo or getting up a Gentoo env for the Pandora, is that what that guide is or am I mixing it up?

The guide is discussing how to build a Gentoo image for an armv7a board. However, the first two pages discuss building a cross-compiler environment. While it is done within Gentoo and uses Gentoo tools to make this environment, what you get is a fairly vanilla cross-compiler, which you can use like you would any other cross-compiler.

 

[Enverex]

Ok great, one last thing, does anyone have a brief guide to building static binaries as opposed to dynamic ones?

Sorry if I've asked a lot of questions, I've had almost no time to actually -try- anything due to work and such, but I can browse the forum on breaks so I'm trying to get a compendium of all possible questions and issues so when I'm working on stuff I won't have to stall.

 

[Pickle]

Ok great, one last thing, does anyone have a brief guide to building static binaries as opposed to dynamic ones?

static and dynamic is pretty simple actually. Its describes how the application interacts with any libraries or 3rd party binary code it might need to use. Static means we are linking the library code directly into the application. We commonly did this with the gp2x since we always wanted to use the community's hw SDL and not GPH shared sw SDL. Bad side effect is that the size gets big.
Dynamic means the application is going to link to libraries during runtime, much like dll's in windows if your familar with windows. The benefit with this is that the application size is small and libraries can be updated without breaking the binary (usually)
You can also link a combination of static and dynamic libraries if you want.
.a are static libraries
.so are dynamic libraries

 

[Enverex]

Thanks for the clarification pickle but I know exactly how it works, its just -how- you make them static rather than dynamic that I'm not sure about.

 

[Pickle]

Thanks for the clarification pickle but I know exactly how it works, its just -how- you make them static rather than dynamic that I'm not sure about.

ok is this your library or an library that builds off autotools? Is this libao?
Autotools you usually just have to add to your configure statement, check configure --help:
--enable-shared
--enable-static

 

[Enverex]

Thanks for the clarification pickle but I know exactly how it works, its just -how- you make them static rather than dynamic that I'm not sure about.

ok is this your library or an library that builds off autotools? Is this libao?
Autotools you usually just have to add to your configure statement, check configure --help:
--enable-shared
--enable-static

I was just thinking for apps in general, i.e. UADE, Widelands, OpenTT, etc.

 

[Pickle]

Thanks for the clarification pickle but I know exactly how it works, its just -how- you make them static rather than dynamic that I'm not sure about.

ok is this your library or an library that builds off autotools? Is this libao?
Autotools you usually just have to add to your configure statement, check configure --help:
--enable-shared
--enable-static

I was just thinking for apps in general, i.e. UADE, Widelands, OpenTT, etc.

Im not sure what your asking, maybe how to link dynamically or statically?

 

[Enverex]

Thanks for the clarification pickle but I know exactly how it works, its just -how- you make them static rather than dynamic that I'm not sure about.

ok is this your library or an library that builds off autotools? Is this libao?
Autotools you usually just have to add to your configure statement, check configure --help:
--enable-shared
--enable-static

I was just thinking for apps in general, i.e. UADE, Widelands, OpenTT, etc.

Im not sure what your asking, maybe how to link dynamically or statically?

Yes sorry, basically I'd like to be able to compile those games/programs/applications, but have them linked statically when I do so. I fear this will depend on the make system they use though (autotools, etc). Although I'm not sure if there are any "this will work for most build systems" methods that can be used which is why I'm asking.

 

[Pickle]

Yes sorry, basically I'd like to be able to compile those games/programs/applications, but have them linked statically when I do so. I fear this will depend on the make system they use though (autotools, etc). Although I'm not sure if there are any "this will work for most build systems" methods that can be used which is why I'm asking.

just add -static to the cflags variable

 

[Enverex]

Running into an issue while trying to cross compile SDL. Not sure what has changed this time around as I did it before, but it's failing now:

/bin/sh ./libtool --mode=compile arm-none-linux-gnueabi-gcc -g -O2 -I/usr/local/pandora/arm-2007q3/include -I./include -D_GNU_SOURCE=1 -fvisibility=hidden    -I/usr/include -DXTHREADS -DHAVE_LINUX_VERSION_H -c ./src/audio/dma/SDL_dmaaudio.c  -o build/SDL_dmaaudio.lo
 arm-none-linux-gnueabi-gcc -g -O2 -I/usr/local/pandora/arm-2007q3/include -I./include -D_GNU_SOURCE=1 -fvisibility=hidden -I/usr/include -DXTHREADS -DHAVE_LINUX_VERSION_H -c ./src/audio/dma/SDL_dmaaudio.c  -fPIC -DPIC -o build/.libs/SDL_dmaaudio.o
cc1: warning: include location "/usr/include" is unsafe for cross-compilation
./src/audio/dma/SDL_dmaaudio.c: In function 'DMA_WaitAudio':
./src/audio/dma/SDL_dmaaudio.c:166: error: impossible constraint in 'asm'
make: *** [build/SDL_dmaaudio.lo] Error 1

Also not sure why it's picking up /usr/include as the configure script specifies - CPPFLAGS="-I$PREFIX/include"
Probably something obvious but I'm sure I'll get the hang of it eventually...

 

[Pickle]

Running into an issue while trying to cross compile SDL. Not sure what has changed this time around as I did it before, but it's failing now:

/bin/sh ./libtool --mode=compile arm-none-linux-gnueabi-gcc -g -O2 -I/usr/local/pandora/arm-2007q3/include -I./include -D_GNU_SOURCE=1 -fvisibility=hidden    -I/usr/include -DXTHREADS -DHAVE_LINUX_VERSION_H -c ./src/audio/dma/SDL_dmaaudio.c  -o build/SDL_dmaaudio.lo
  arm-none-linux-gnueabi-gcc -g -O2 -I/usr/local/pandora/arm-2007q3/include -I./include -D_GNU_SOURCE=1 -fvisibility=hidden -I/usr/include -DXTHREADS -DHAVE_LINUX_VERSION_H -c ./src/audio/dma/SDL_dmaaudio.c  -fPIC -DPIC -o build/.libs/SDL_dmaaudio.o
 cc1: warning: include location "/usr/include" is unsafe for cross-compilation
 ./src/audio/dma/SDL_dmaaudio.c: In function 'DMA_WaitAudio':
 ./src/audio/dma/SDL_dmaaudio.c:166: error: impossible constraint in 'asm'
 make: *** [build/SDL_dmaaudio.lo] Error 1

Also not sure why it's picking up /usr/include as the configure script specifies - CPPFLAGS="-I$PREFIX/include"
Probably something obvious but I'm sure I'll get the hang of it eventually...

Yeah that /usr/include is being added in somewhere, but I dont think thats the real problem. You have some asm trying to be compiled its probably x86 asm. You need to take a long at that file and determine if that code can excluded. If it cant then the only option is to rewrite it in C or in ARM asm.

 

[Enverex]

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...)