forcing the right version via flags. More dumb questions

[twobob]

I have a question, probably been asked before but I will ask it again as I didn't find the answer yet.

Looking on a binary that has been built with a later TC to attempt to run on the Kindle 3

We can see that this example here will have an issue...

root@kindle:root> readelf -s /mnt/us/usr/lib/libavformat.so.53 | grep "2\.7"

113: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (9)

so my question is threefold

a) what flags would cover - say - a case to convince the pre-processor to pull a 2.6 ver of isoc99_sscanf if we were to recompile it from source but with a Later TC.

b) how can I learn the general process thought process behind determining this to prevent asking dumb questions like this one

c) Is this a dumb question. ie. you just can't. or something else I didn't consider fully.

Also like to point out that __isoc99_sscanf@GLIBC_2.7 is just an example and I'm not actually atttempting to recompile that file. well, I am as it happens, but that is irrelevant to this question - which is one about general principles.

Thanks.

[knc1]

I think that is controlled by the soname conventions.
With a few exceptions (libc, ??) it goes like:
gcc ... ... -lavformat ... ...
Which gets string mangled into: libavformat.so (the processing of "-l') - - -

Then the library search path is traversed, looking for that file ;
-L<whatever>:/lib:/usr/lib
With a bit of sysroot thrown in for the flavor.

Found (in the above case):
sym-link, libavformat.so -> libavformat.so.53.0
Possible will be a chain of symlinks until you reach the full version named library file.

Now your specific symbol name is about the "exception" I mentioned above, the C library.

You might be able to change which one that gcc is referring to in its "specs" file.
gcc --dump-specs (I think) should print it for you; grep can find it for you.

Otherwise you will have to dig through the release notes of the toolchain bundle to see which version C library the tool chain was built against.

GLIBC_2.7 replaced GLIBC_2.6 somewhere along the line between 4.2 and 4.7

We already know (the hard way) that we don't want to use gcc-4.7 with the old Kindles;
You may have to use the "power of Buildroot" to churn out a gcc-4.6 tool chain with the older glibc release selected.

How much tea can you drink in the hours that will take to execute?

[twobob]

well. I managed two cups so far and that included one death resulting from including "CV" (even with the latest TC)

I will automate it in the end.

[twobob]

gcc --dump-specs would be awesome on the kindle. but we don't have a gcc yet.

[knc1]

Originally Posted by twobob

gcc --dump-specs would be awesome on the kindle. but we don't have a gcc yet.

That should be checked in the tool-chain that is doing the building.
Or, cross tool-chain in this case.

You have a gcc somewhere - don't try to confuse me with the facts.

[twobob]

HAHAHA good point.

I was simply pointing out -the blindingly obvious- that it would be handy to have that native as well.

I'll dig around in the guts of TARGET (STAGING) or HOST and see what I can dredge maybe there are a few remnants that can be evoked into service now you mention it.

[twobob]

a handy... Did I foof? test.

Don't expect fast results if you run 2 Gb of software...

root@kindle:root> readelf -s /mnt/us/usr/lib/* | grep -s "GLIBC_2\.7"

or readelf -s /mnt/us/usr/lib/*so* | grep -s "GLIBC_2\.7"

if the folder errors annoy you.

Spoiler:

readelf: Error: '/mnt/us/usr/lib/ImageMagick-6.7.8' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/alsa-lib' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/ao' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/apr-util-1' is not an ordinary file
readelf: Error: Unable to read in 0x2074 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Unable to read in 0x4445 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/beecrypt' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/bellagio' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/cairo' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/cmake' is not an ordinary file
readelf: Error: Unable to read in 0x5320 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/directfb-1.4-6' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/efreet' is not an ordinary file
readelf: Error: Unable to read in 0x2066 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/engines' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/esmtp-plugins' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/evas' is not an ordinary file
readelf: Error: Unable to read in 0x2066 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/fonts' is not an ordinary file
readelf: Error: Unable to read in 0x5320 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/gdbus-2.0' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/gio' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/gstreamer-0.10' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/icu' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/imlib2' is not an ordinary file
readelf: Error: Unable to read in 0x2066 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Unable to read in 0x666f bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/ldscripts' is not an ordinary file
215: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (7)
215: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (7)
215: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (7)
113: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (9)
113: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (9)
113: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (9)
39: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (4)
39: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (4)
39: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (4)
54: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (3)
54: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (3)
54: 00000000 0 FUNC GLOBAL DEFAULT UND __isoc99_sscanf@GLIBC_2.7 (3)
readelf: Error: '/mnt/us/usr/lib/libxslt-plugins' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/mpg123' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/mysql' is not an ordinary file
readelf: Error: Unable to read in 0x5753 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/omxloaders' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/opkg' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/perl5' is not an ordinary file
readelf: Error: Unable to read in 0x5320 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/pulse-2.0' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/pulseaudio' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/python2.7' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/qt' is not an ordinary file
readelf: Error: Unable to read in 0x2066 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/ruby' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/sa' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/sigc++-2.0' is not an ordinary file
readelf: Error: '/mnt/us/usr/lib/tcl8.4' is not an ordinary file
readelf: Error: Unable to read in 0x6873 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: '/mnt/us/usr/lib/terminfo' is not an ordinary file
readelf: Error: Unable to read in 0x2066 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Unable to read in 0x7972 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
readelf: Error: Unable to read in 0x7261 bytes of section headers
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

so in this case you can see there would be trouble.
next up. finding exactly which files to rebuild (as STANDARD INPUT isn't very helpful as a file name hehehe)

[twobob]

hmmm okay.

The QT. Webkit. X build weighs in at a mighty 500 MB and that's BEFORE I duplicate it all up.

err. no. that's too big. but it did build. : )

I am already down to 600Mb space on my FAT partition with my current huge software install.

time to do some trimming of the chuff.

[NiLuJe]

@twobob: Usually, a quick round of checking the system's headers + google will get you the answer.

If it's a project using autotool, there's generally a configure-time check responsible for checking the system's libc that may be overridden manually. But you may also need/want to hack around the sources/headers of the project directly (see what I did for coreutils for example) to dumb it down.

grep -r & readelf are your friends .

The scanf case might be one of the trickier, if I remember correctly, you'll have to either build with gcc set to a particular -std that doesn't handle C99, or build with _GNU_SOURCE defined. That might not be viable workarounds for every projects out there...

[twobob]

Originally Posted by NiLuJe

@twobob: Usually, a quick round of checking the system's headers + google will get you the answer.

If it's a project using autotool, there's generally a configure-time check responsible for checking the system's libc that may be overridden manually. But you may also need/want to hack around the sources/headers of the project directly (see what I did for coreutils for exeample) to dumb it down.

grep -r & readelf are your friends .

The scanf case might be one of the trickier, if I remember correctly, you'll have to either build with gcc set to a particular -std that doesn't handle C99, or build with _GNU_SOURCE defined. That might not be viable workarounds for every projects out there...

This is great info. I am honestly just beginning to understand even a tiny part of the construct but every little helps me provide better output.

Much appreciated. These little tricks and touches make all the difference for a finicky target like the kindles.

[twobob]

I am slowly working my way back through the chains to see what is the last chain that will run without issue.

2009q1-203 currently in the grinder.

[twobob]

Okay it looks like arm-2008q1 is the last 4.2.x Glib - this is derived from where I would install the kernel headers

Updated the buildroot bug report to reflect this
https://bugs.busybox.net/show_bug.cgi?id=5486

2008q3 goes to 4.3.x which I assume is the break to 2_7... correct me if I'm wrong.

Would that be the info I have been looking for?
The final departure point of CS away from 2.6

Going to skip down to 2008q1 and build up from there. see what shakes.

I've cleared down 2.7 Gb of software in readiness for a nice clean install.
Amazing how that stuff just piles up.

[knc1]

The executable components of the tool-chain itself will be built against libc -
Use your symbol search command to test for the 2.6/2.7 symbols.

Not a "worked solution" just the first thing I would try.

[twobob]

Okay so: 2008q1-126 first incidence of failure:

CCLD libglib-2.0.la
CCLD gtester
./.libs/libglib-2.0.so: undefined reference to `qsort_r'

will try next one up...

My word this is slow work

I suppose I *COULD* try implementing the qsort_r=no fix in a little while - see if qsort_r really ISNT in the older glibc. but IIRC correctly it is; so that's possibly another error made manifest.

[twobob]

Originally Posted by knc1

The executable components of the tool-chain itself will be built against libc -
Use your symbol search command to test for the 2.6/2.7 symbols.

Not a "worked solution" just the first thing I would try.

I tried this but must have done it wrong.
Only found reference to really old GLIB like 2.0 in all of them.

2006 -- > 2012 ?

foofed.