71 replies to this topic

[Ivanovic]

In case you get some error like this one:

/home/nils/pandora-dev/arm-2010.09/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.1/../../../../arm-none-linux-gnueabi/bin/ld: warning: libstdc++.so.6, needed by /home/nils/pandora-dev/arm-2010.09/usr/lib/libboost_regex-mt.so, not found (try using -rpath or -rpath-link)

Seems that something really strange is going on, but adding -rpath really fixes it. This is what the resulting line from the makefile looks like once fixed:

$(CXX) -g $(OPT) -L$(PREFIX)/usr/lib -Wl,-rpath=$(PREFIX)/usr/lib -D_GNU_SOURCE=1 -D_REENTRANT -Wnon-virtual-dtor -Wreturn-type -lSDLmain -lSDL -lGLES_CM -lGLUES_CM -lIMGegl -lEGL -lsrv_um -lX11 -lXau -lXdmcp -lSDL_image -lSDL_ttf -lSDL_mixer -lts -lpng12 -ljpeg -lz -lfreetype -lmad -ltiff -lboost_regex-mt -lboost_system-mt -fthreadsafe-statics $(objects) -o game

Basically adding -Wl,-rpath=$PNDSDK/usr/lib does the trick.

[PokeParadox]

Thanks for the work on this... if this is going to be the "official" toolchain, I'll move Penjin over to using this.

[Ivanovic]

Another update to the toolchain linked in this post. Changelog:

• Create missing file usr/bin/libpng-config.
  
• Create missing file usr/lib/pkgconfig/lua5.1.pc.
  
• Simplify the section used during fixing libs. Commented out some parts that should not be required there since they were already covered by the stuff done before.
  
• Supply more "useful files" and place them in a dir of their own (PNDSDK_DIR/sdk_utils/). List of files:
  
  • PandoraToolchain.cmake: useful for crosscompiling with cmake.
    
  • pandora_configure.sh: wrapper around ./configure that allows calling configure via this script and directly setting most vars that should be required to run it.
    
  • opkg-pandora.sh: script for calling opkg in a way that the stuff setup is used correctly.
    
  • fix-libs.sh: script to fix libs. Eg required after running some opkg update.
    
  • pnd_make.sh: script for packaging things into a .pnd.
    
  • genpxml.sh: script for generating some basic PXML.xml file.

Edited by Ivanovic, 31 January 2011 - 04:52 PM.

[crow_riot]

just a quick question, which libs does this package include? for me gles, sdl(mixer) , ibvorbisfile and stuff like that are quite important... do you have a list ?

[sebt3]

He include everything that are available on pandora

[sverm]

Is there a recommended environment-setup.sh as well? It seems sebt3's from earlier is pointing to the paths off root, or the paths don't match the newer SDK. I've had to take out many $TARGET_SYS here and there. I'm just not convinced I should have been using that one.

For instance

#export PATH=$SDK_PATH/bin:$PATH:$SDK_PATH/$TARGET_SYS/usr/bin
export PATH=$SDK_PATH/bin:$PATH:$SDK_PATH/usr/bin

And I've also tried opkg-target install libsdl1.2-dev to no avail. Something about the architecture being missing. I'll try again with this newer installer script.

[sebt3]

Is there a recommended environment-setup.sh as well? It seems sebt3's from earlier is pointing to the paths off root, or the paths don't match the newer SDK. I've had to take out many $TARGET_SYS here and there. I'm just not convinced I should have been using that one.

For instance

#export PATH=$SDK_PATH/bin:$PATH:$SDK_PATH/$TARGET_SYS/usr/bin
 export PATH=$SDK_PATH/bin:$PATH:$SDK_PATH/usr/bin

And I've also tried opkg-target install libsdl1.2-dev to no avail. Something about the architecture being missing. I'll try again with this newer installer script.

My environnement setup is for djwillis toolchain (as this is what I do use).
The newer wrapper scripts Ivanovic have added, are based of my posts and are to get the same effects.

[Bryce Leo]

Ivanovic is it safe to just re-run this into a folder it's been installed in to already? Do i need to delete the contents of the folder before re-running?

Sverm here's what I used to get pcsx-rearmed to compile.

Environment

export SDK_PATH=/home/bryce/ivtoolchain/arm-2010.09
export TARGET_SYS=arm-none-linux-gnueabi
export PATH=$SDK_PATH/bin:$PATH
export CPATH=$SDK_PATH/$TARGET_SYS/usr/include:$SDK_PATH/usr/include:$CPATH
export LD_LIBRARY_PATH="/home/bryce/ivtoolchain/arm-2010.09/lib:/home/bryce/ivtoolchain/arm-2010.09/usr/lib:${LD_LIBRARY_PATH}"
export LIBTOOL_SYSROOT_PATH=$SDK_PATH/$TARGET_SYS
export PKG_CONFIG_SYSROOT_DIR=$SDK_PATH/$TARGET_SYS
export PKG_CONFIG_PATH=$SDK_PATH/$TARGET_SYS/usr/lib/pkgconfig
export CONFIG_SITE=$SDK_PATH/site-config
alias opkg="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH//etc/opkg-sdk.conf -o $SDK_PATH"
alias opkg-target="LD_LIBRARY_PATH=$SDK_PATH/lib $SDK_PATH/bin/opkg-cl -f $SDK_PATH/$TARGET_SYS/etc/opkg.conf -o $SDK_PATH/$TARGET_SYS"

Makefile additions

CROSS_COMPILE=arm-none-linux-gnueabi-
AS = $(CROSS_COMPILE)as
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld

ARCH = $(shell $(CC) -v 2>&1 | grep -i 'target:' | awk '{print $$2}' | awk -F '-' '{print $$1}')

CFLAGS += -ggdb -Ifrontend
LDFLAGS += -L/home/bryce/ivtoolchain/arm-2010.09/usr/lib -lz -lpthread -ldl -lpng -lbz2
#LDFLAGS += -lz -lpthread -ldl -lpng 

Edited by Bryce Leo, 01 February 2011 - 02:17 AM.

[Ivanovic]

Ivanovic is it safe to just re-run this into a folder it's been installed in to already? Do i need to delete the contents of the folder before re-running?

Yes, it should work to just rerun the script. In case you observe any problems, delete the folder "arm-2010.09" and it should reinstall everything. Keep in mind that you need the whole lot of tmp files from before, or it will probably try redownloading stuff...

[silver]

Thanks for putting this script together - making life a lot easier. I've just been compiling on the Pandora up to know (faster than expected with a little OC) although I've been crashing GCC due to not enough memory when compiling with PGO...

Hope this gets the official nod for standardised way to cross-compile...

[Ivanovic]

Another update to the toolchain linked in this post. JayFoxRox requested some changes/additions in the script, here they are. Changelog:

• Added a symlink from all files in bin/ folders being named $TARGET_SYS-something (usually arm-none-linux-gnueabi-something) to pandora-something. This eg make accessing gcc by far easier. Instead of remembering arm-none-linux-gnueabi-gcc as binary name, you can just use pandora-gcc.
  
• Added the environment variable $PNDSDK to ~/.bashrc. If you are using bash as login shell you will now have the variable set allowing you to easily access stuff from the toolchain. This way you can eg call the gcc of the toolchain by simply calling $PNDSDK/bin/pandora-gcc

[sverm]

Awesome ideas. It's getting easier to use every day! Would you also recommend pre-pending $PNDSDK/arm-2010.09/bin to the path?

Edited by sverm, 01 February 2011 - 11:36 PM.

[silver]

Trying to use this setup (Ubuntu 10.03, 32bit, in a VM - latest toolchain applied) to compile PUAE (https://github.com/GnoStiC/PUAE)

Compiles fine natively on the Pandora (once you add all the missing libs and build tools).

It's a bit messy (to my eyes) - relies on autoconf/automate/aclocal prior to calling a ./configure and make... Substituting in the pandora_configure.sh within the build_pandora_gtk.sh script, things don't get that far:

It crashes out because it can't find the relevant header files. They are pointed to in the Makefile.in via the @top_srcdir@ variable - but this does not appear to work correctly. i.e. it changes to a subdir ( ./src/tools) to compile some UAE tools first, but source files in ./src/tools reference .h files in ./src/include - so it looks like the variable is not passed correctly. I assume this may because the autocong is running not setup for a cross-compile?

Any pointers - can add logs etc..., but perhaps I should make a new thread? Don't want to mess this one up.

[Ivanovic]

Trying to use this setup (Ubuntu 10.03, 32bit, in a VM - latest toolchain applied) to compile PUAE (https://github.com/GnoStiC/PUAE)

Compiles fine natively on the Pandora (once you add all the missing libs and build tools).

It's a bit messy (to my eyes) - relies on autoconf/automate/aclocal prior to calling a ./configure and make... Substituting in the pandora_configure.sh within the build_pandora_gtk.sh script, things don't get that far:

It crashes out because it can't find the relevant header files. They are pointed to in the Makefile.in via the @top_srcdir@ variable - but this does not appear to work correctly. i.e. it changes to a subdir ( ./src/tools) to compile some UAE tools first, but source files in ./src/tools reference .h files in ./src/include - so it looks like the variable is not passed correctly. I assume this may because the autocong is running not setup for a cross-compile?

Any pointers - can add logs etc..., but perhaps I should make a new thread? Don't want to mess this one up.

You should in theory be able to normally run all the autoconf/automake/aclocal stuff with the software from your normal host system. The autofoo stuff before running configure should be completely independent from native or cross compiling. Afterwards you should have a clean "configure" script which can be used with the SDK. Yeah, autotools are a mess and it is likely that pandora_configure.sh does not work perfectly in all situations. So I'd recommend you to retry things with your native system, once it compiles nicely there you should try it with the crosscompiler script. If you still have probs I think they are more easily solved in an additional thread.

[Ivanovic]

Another update to the toolchain linked in this post. I tried getting qmake to work with the crosscompiler toolchain which resulting in me implementing some changes:

• Added basic scripts for qmake support with the SDK. The files will end in $PNDSDK/../sdk_utils/qmake_linux-pandora-g++. With those you should be able to easily compile using qmake. Here is an example call that I used to compile smplayer:
  

  make QMAKE="qmake -spec $PNDSDK/../sdk_utils/qmake_linux-pandora-g++"

• Since qmake/smplayer required the Qt libs to be ending in ".so" instead of ".so.4" or even longer versions I added symlinks from all libQt*.so.4 files to libQt*.so. This way it is at least possible to compile SMPlayer.