GP2X Gph Toolchain For Linux With Gcc 4.0.3 And Gp2x Kernel 2.1.x

[Blah]

From what I've read, it would involve having an older compiler build glibc. To do this in crosstool you set GCC_DIR=highercompiler and GCC_CORE_DIR=lowercompiler.
But I'm getting ahead of myself here...

As for distributing, I will give DJWillis the patches & miscellany when/if the time comes as I'm sure he would be interested.
edit: meh, I'm too lazy for that.

 

[Kalimerou]

Have you tried using STerm / or via a ssh-conection - it should be the tool of choice to debug console apps

Thanks for the advice, I'll try this evening to see what happens. Indeed, I didn't even know STerm h34r:
and I wondered why Midnight Commander was crashing my handheld...

Thanks again, I finally got MC to run.

I tried yesterday to compile a toolchain with gcc 4.1.1 and glibc 2.2.5, but the build failed.
By the way, I wonder : why does it seem so important to use the 2.2.5 version of the glibc ??
I understand people trying to use gcc 4.1, because it greatly improves the code performance. But why stuck on glibc 2.2.5 ?
Is it because it would be the gp2x native version ? is it really important ? I believe that it would be possible to put the glibc v2.3.6 once somewhere, and then use it as a shared library for all compiled binaries... what about that ?

 

[Mudi]

I actually have managed to use glibc 2.3 as a shared library on the GP2X, I just copied a couple library files and forced them to load using LD_PRELOAD on the GP2X. But this is hardly ideal, and I find there are very few things that glibc 2.2.5 doesn't do just as well. Having a toolchain with gcc 4 and glibc 2.2.5 would be great, because I think you should be able to use profiling and all that with dynamic linking, but quite honestly I didn't think it was possible.

 

[Blah]

Glibc-2.3.6 and co. take up too much space to be packaging along with our binaries. A firmware update would be ideal, but for now we have to work with what GPH gave us.

 

[Kalimerou]

Glibc-2.3.6 and co. take up too much space to be packaging along with our binaries. A firmware update would be ideal, but for now we have to work with what GPH gave us.

It seems like there is an underlying issue. :unsure:
On the one hand, the GP2x comes bundled with a (perhaps tweaked) shared glibc 2.2.5 library we could link with our own programs. But the use of gcc 3.4 would produce executable with possibly lower performance, so it's better no to make this choice.
On the other hand, the use of gcc 4 will produce a "better" code, but also impact the executable size because of the static link.
Moreover, are we sure that a binary produced by gcc 4 and which links the GP2x glibc as a shared library would be compatible with its object code (produced by gcc 3.4) ???
To my mind, and until someone can tell me how to compile the glibc 2.2.5 using gcc 4.1.1, I think that with the greater and greater capacities we could have on SD-cards, size does not really matters.
But you may not agree

 

[Mudi]

Actually, gcc 3.4 produces very nice code... I'm not too concerned about the quality of the produced code, I'm more interested in the new features of gcc 4 (like profiling, etc)

 

[Kalimerou]

Actually, gcc 3.4 produces very nice code... I'm not too concerned about the quality of the produced code, I'm more interested in the new features of gcc 4 (like profiling, etc)

Rather than code quality, it also concerns the performance of your executable. An optimized code is a code which runs faster !
On GP2x, for a piece of software like an SNes emulator, it's quite important indeed

 

[Blah]

GCC 4.1.1 + glibc 2.2.5 + Binutils 2.17 ARM (no softfloat ) compiled. Now I have to hack glibc into compiling with softfloat and I need to hack binutils also or switch back to Binutils 2.16.1

 

[Kalimerou]

GCC 4.1.1 + glibc 2.2.5 + Binutils 2.17 ARM (no softfloat ) compiled. Now I have to hack glibc into compiling with softfloat and I need to hack binutils also or switch back to Binutils 2.16.1

How the hell did you manage to do this ?
Did you have to patch something ? would you have a script to give us ?

 

[Blah]

I used crosstool-0.43 (www.kegel.com/crosstool) and the following configuration files:

[crosstool_dir]/gp2x.sh

#!/bin/sh
# This script has one line for each known working toolchain
# for this architecture.  Uncomment the one you want.
# Generated by generate-demo.pl from buildlogs/all.dats.txt <-- No, it wasn't xD

set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES

# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP

eval `cat arm.dat gp2x.dat` sh all.sh --notest

echo Done.

[crosstool_dir]/gp2x.dat

BINUTILS_DIR=binutils-2.16.1
GCC_CORE_DIR=gcc-3.4.5
GCC_DIR=gcc-4.1.1
GLIBC_DIR=glibc-2.2.5
LINUX_SANITIZED_HEADER_DIR=linux-libc-headers-2.6.12.0
GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.2.5

[crosstool_dir]/patches/glibc-2.2.5/glibc-allow-anygcc.patch #The slightly evil hack

--- glibc-2.2.5/configure	2007-02-03 11:46:22.000000000 -0800
+++ glibc-2.2.5/configure-hack	2007-02-03 11:49:13.000000000 -0800
@@ -1475,10 +1475,10 @@
 echo "configure:1476: checking version of $CC" >&5
   ac_prog_version=`$CC -v 2>&1 | sed -n 's/^.*version ([egcygnustpi-]*[0-9.]*).*$/\1/p'`
   case $ac_prog_version in
-	') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
+	') ac_prog_version="v. ?.??, bad"; ac_verc_fail=no;;
	 *gcc-2.9[5-9].*|*2.8.[1-9]*|*2.9|*2.9.[0-9]*|2.9[5-9]*|3.[0-9]*|4.0*|cygnus-2.9[1-9]*|gcc-2.9[5-9]|gcc-2.1[0-9][0-9]|sgicc-*)
		ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
-	*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
+	*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=no;;
 
   esac
   echo "$ac_t""$ac_prog_version" 1>&6

Its still not good enough for me though, so I'm still working on it.

 

[Kalimerou]

[crosstool_dir]/patches/glibc-2.2.5/glibc-allow-anygcc.patch #The slightly evil hack

--- glibc-2.2.5/configure	2007-02-03 11:46:22.000000000 -0800
+++ glibc-2.2.5/configure-hack	2007-02-03 11:49:13.000000000 -0800
@@ -1475,10 +1475,10 @@
 echo "configure:1476: checking version of $CC" >&5
   ac_prog_version=`$CC -v 2>&1 | sed -n 's/^.*version ([egcygnustpi-]*[0-9.]*).*$/\1/p'`
   case $ac_prog_version in
-	') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
+	') ac_prog_version="v. ?.??, bad"; ac_verc_fail=no;;
	 *gcc-2.9[5-9].*|*2.8.[1-9]*|*2.9|*2.9.[0-9]*|2.9[5-9]*|3.[0-9]*|4.0*|cygnus-2.9[1-9]*|gcc-2.9[5-9]|gcc-2.1[0-9][0-9]|sgicc-*)
		ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
-	*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
+	*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=no;;
 
   esac
   echo "$ac_t""$ac_prog_version" 1>&6

Ha ha !! h34r: this is what I missed !
I'll try soon to merge this into the GPH script Thanks !

 

[Blah]

See if you can get 4.1.1 softfloat working, trust me I don't know any more than you do about this.

 

[Blah]

GCC 4.1.1 + Glibc-2.2.5 softfloat compiled! This patch I made fixes softfloat in later versions of gcc.

Note: Linking will fail without -msoft-float cflag. I think I can fix that though.

edit: Thats normal behavior for GCC apparently (so that if you build a hardfloat glibc, etc, it will work with the same compiler).

--- gcc-4.1.1/gcc/config/arm/linux-elf.h	2005-10-09 18:04:31.000000000 -0700
+++ gcc-4.1.1/gcc/config/arm/linux-elf.h	2007-02-07 23:15:48.000000000 -0800
@@ -49,7 +49,7 @@
	%{shared:-lc} \
	%{!shared:%{profile:-lc_p}%{!profile:-lc}}"
 
-#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -lgcc"
+#define LIBGCC_SPEC "-lgcc"
 
 #define LINUX_TARGET_INTERPRETER "/lib/ld-linux.so.2"

 

[Kalimerou]

GCC 4.1.1 + Glibc-2.2.5 softfloat compiled! This patch I made fixes softfloat in later versions of gcc.

Note: Linking will fail without -msoft-float cflag. I think I can fix that though.

edit: Thats normal behavior for GCC apparently (so that if you build a hardfloat glibc, etc, it will work with the same compiler).

--- gcc-4.1.1/gcc/config/arm/linux-elf.h	2005-10-09 18:04:31.000000000 -0700
+++ gcc-4.1.1/gcc/config/arm/linux-elf.h	2007-02-07 23:15:48.000000000 -0800
@@ -49,7 +49,7 @@
	%{shared:-lc} \
	%{!shared:%{profile:-lc_p}%{!profile:-lc}}"
 
-#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -lgcc"
+#define LIBGCC_SPEC "-lgcc"
 
 #define LINUX_TARGET_INTERPRETER "/lib/ld-linux.so.2"

Well I was also having failures during linking, so I fell down to 4.0.3.
It take so long to compile such a toolchain that I'm lazy to try and try again...

 

[Blah]

The GP2X Toolchain Project has been registered by me at Gna! Theres nothing there yet though.