Cross compiling for the Kindle - wrong glibc version

[ninjageckoattack]

I have been trying to set up a machine to cross-compile for the Kindle. I have been able to make a simple "Hello world" program and run it, but anything more complicated than that seems to fail.
For example, trying to compile the kindle terminal program works, but running it gives the error:
"./myts.arm: /lib/libc.so.6: version `GLIBC_2.7' not found (required by ./myts.arm)"
I am using scratchbox2 and CodeSourcery's arm-none-linux-gnueabi toolchain to compile it. I have tried copying the /lib and /usr/lib directories from my kindle to my computer and setting gcc's sysroot to their location, but that results in the error that crt1.o and crti.o cannot be found. How do I compile using the Kindle's version of these libraries?

[TJW]

use glibc 2.5 toolchain instead.

[NiLuJe]

Or, if the program you're trying to build doesn't really use newer glibc features, you can avoid pulling the whole set of GLIBC_2.7 symbols related to the fortify & stack smashing features of newer glibc/gcc couples by putting

-fno-stack-protector -U_FORTIFY_SOURCE

in your CFLAGS.

That won't help you if your program actually *wants* to use newer glibc features (depending on the feature in question, it might be easy enough to hack around it).

readelf is your friend to check you're not pulling unwanted symbols .

(I'm using a GCC 4.5/Glibc 2.9 TC to build stuff for the hacks, for example, and I have yet to run into more trouble than a silly hack in coreutils to avoid ABI mismatches).

[ninjageckoattack]

I tried putting those two commands in my CFLAGS, but it did not help the problem. In fact, running diff on the binaries with and without those flags showed that those flags do not change the output of the compiler at all.

[NiLuJe]

That's assuming the stuff you're trying to build doesn't have an utterly broken buildsystem, and actually respects CFLAGS and stuff like that .

Anyway, readelf is your friend to pinpoint which symbol(s) are problematic.

[ninjageckoattack]

ok, so after taking a crash course in readelf, I have found out that sscanf is the function pulling GLIBC 2.7. I have a working version of the executable compiled by someone else to compare it to. In the working version, readelf gives the lines:

    36: 0000902c     0 FUNC    GLOBAL DEFAULT  UND sscanf@GLIBC_2.4 (2)
   427: 0000902c     0 FUNC    GLOBAL DEFAULT  UND sscanf@@GLIBC_2.4

However, in my version, it gives me the lines:

    13: 00008efc     0 FUNC    GLOBAL DEFAULT  UND __isoc99_sscanf@GLIBC_2.7 (4)
   383: 00008efc     0 FUNC    GLOBAL DEFAULT  UND __isoc99_sscanf@@GLIBC_2.

Why would this code be using glibc 2.7 when the function is clearly available in glibc 2.4?

[NiLuJe]

Try adding -ansi to your CFLAGS. If it doesn't break anything, that'll make sure no c99 symbols get pulled.

EDIT: If you don't care about portability (in this case, it shouldn't matter, we know that our target system will always be Linux/glibc 2.5), -D_GNU_SOURCE is another way to workaround this (and is probably less likely to break stuff). That's what I usually do in the sscanf case, in fact.

[hawhill]

Depending on how much you intend to work with the toolchain, I'd strongly suggest using a glibc 2.5 based one. Otherwise, you'll always be chasing these kind of errors and it all sums up in a much bigger effort than just compiling a matching toolchain.

[NiLuJe]

True. I only build a small amount of 'simple' stuff, and have some experience dealing with these kinds of issues, so it doesn't bother me much, but depending on what you intend to build, it might get pretty hairy .

[ninjageckoattack]

Thank you for your help, I was able to compile the program and run it with the -D_GNU_SOURCE option. I have tried to just use a glibc 2.5 toolchain, but I don't know where/how to get one. I tried using the OSELAS.Toolchain, but compiling it always gave me some errors. Anyways, this worked.

[kindle3zeng]

Originally Posted by ninjageckoattack

Thank you for your help, I was able to compile the program and run it with the -D_GNU_SOURCE option. I have tried to just use a glibc 2.5 toolchain, but I don't know where/how to get one. I tried using the OSELAS.Toolchain, but compiling it always gave me some errors. Anyways, this worked.

If you're using Linux, you can try this one, I built it on Ubuntu 10.10. I used it to compile some large software(VIM, Python, etc.), and I didn't encounter any problem yet:
https://rapidshare.com/files/3271781...cc4.2.4.tar.gz

[ninjageckoattack]

OK, cool. I downloaded that toolchain, and got it working with scratchbox2. Interesting note: when you are running sb2-init, it is very important to give the full path to qemu or whatever you are using for cpu transparency. Pathetically enough, that was what gave me the most trouble.

[thatworkshop]

Can someone provide me with a qemu on/for Armel please?
Note: I don't want qemu-system-arm as it is for a scenario where the target platform is ARM and not the host. (ie. to run qemu ON Kindle).

[Nyoxi]

Originally Posted by cscat

(ie. to run qemu ON Kindle).

May I be so bold as to ask what is the reason behind it? Just curious.

EDIT: Optware seems to have the qemu. You can use opkg/ipkg to install it (search the forum for that). It only supports i386, however.

[thatworkshop]

Originally Posted by Nyoxi

May I be so bold as to ask what is the reason behind it? Just curious.

EDIT: Optware seems to have the qemu. You can use opkg/ipkg to install it (search the forum for that). It only supports i386, however.

I'd like to just play around, eg. emulate DSL on my Kindle and etc. (with care, because I don't want to brick my Touch again!)

I tried that qemu but reason for asking here was if anyone with a gcc in their Kindle has compiled qemu or not? That'll have support for more than just i386 I suppose!