@twobob: The easier way to do that is probably to tell whatever you're using to build your toolchain (buildroot? ct-ng?) to use *this* specific glibc version when building your x-tc. (That does imply rebuilding *everything*, the toolchain, and each of every other stuff you might have built ifor your staged sysroot).

I rather thought you might say that.

Hmm not sure I can point BR at an older glibc version but Ill go find out. possibly... : )

I do have a gentoo installation on my machine now (err but I still can get my x server to boot so I shelved it) perhaps one say I will have a play on there also - one day.

Honestly expected far less success. I would be intrigued to know if I can get more built with the more recent c version. A lot of the them choked on C errors IIRC... (well obviously errors in c I mean language specific looking deaths)

So that's a big driver for me in terms of 'should I bother?'

As a test I just renamed the extra libc.so.6.NEW & libc-2.3.6.so.NEW, which results in all the apps loading beautifully - that I have tested so far.

@twobob/knc1: Yeah, the glibc's ABI backwards compatibility has been pretty solid, in my experience, without too much burden . That's why your current binaries should work with the Kindle's newer glibc. (Keep in mind that glibc isn't only libc.so, though, there a whole bunch of other core library in there: libm, libcrypt and libdl being the most prominent of those).

For a stark comparison, libstdc++ is a whole different kettle of fish. There *is* ABI compatibility, but there have been so much change in the API over the years that you usually *need* to ship it/static link it to make sure it won't blow up, especially on older systems...
There's still a libstdc++-v3 package available in nearly every distro out there to provide support for older dynamically linked binary/proprietary C++ apps for this very reason.

@twobob: That's essentially what most binary/proprietary apps/games distributed out of a PMS do. Use a wrapper script that tweaks the searchpaths to use their bundled libs over the system's.

You don't even strictly need to reset the env later if you're not doing anything else, since you're tweaking the env of *this* process and its potential children, and this process just returns at the end of the script.

(You can also just one-line it using the neat little 'env' tool from coreutils (busybox has an applet for it, too. No idea if it's enabled on the K3). env BLAH=blah BLUH=bluh /bin/blah)

FFTW (3.3) is a C subroutine library for computing the discrete Fourier transform (DFT) in one or more dimensions, of arbitrary input size, and of both real and complex data (as well as of even/odd data, i.e. the discrete cosine/sine transforms or DCT/DST).

We believe that FFTW, which is free software, should become the FFT library of choice for most applications.

For the purposes of conversation here, let us say that the above code implements the requirements of your chosen distribution policy (it does/will).
Whatever the final version of that "policy implementor" becomes, the above demonstrates the overall behavior.

(Sorry if this reads like I am preaching/teaching or something else, no insult intended to anyone, not even if the above meets the GM whitespace standard.)

Next (rhetorical) question:
How to avoid writing (or having the build system write) one of those above for each and every new application?
In answer, start by reading what is written above in the prototype launcher glue.

What does the first two characters, the Splat-Bang, in a *nix script do?
It causes the loading mechanism used to start an executable to search for a program (other than the elf loader) to interpret the rest of the file.

Now, ask yourself, what mechanism does binfmt_misc provide?
It is a loading mechanism that selects a program to interpret the rest of the file based on either extension or magic number.
The "program" may be any executable, including a script "wrapper".

Ah, so, as the light begins to dawn ....
Now we can see why that crazy old fool was asking for mod binfmt_misc.

Suppose that the above single line glue code began with a six character magic number:

Now all you need is one "wrapper" that binfmt_misc can call when it detects a new executable that needs: "launcher glue".
That wrapper can be used to determine the variables of the "glue code" launcher.

For a more advanced usage, to get a Kindle to "swallow" anything we add-in, see the following reference.

You will find examples of how binfmt_misc can read the elf header of the file to be run.
One of the first things in the elf header is the interpreter to be used and some other flag bits.

I.E: Not only can we "glue in" applications using a mis-matched glibc, we can "glue in" applications that aren't even built against glibc of any version.
(the uClibc loader has a different name, only I need to re-build the uClibc used in the emulator because the current one was built without a required option).

Note: The binfmt_misc mecanisum is the base upon which a loader for signed binaries can be built.

Amazon/lab126 requires a signed update file to make changes to the installed system but **assumes** anything found on the file system was the result of such a signed installation process.

I.E: The Kindles call the OTA updater by name, but as far as its coding can tell, the thing with the "OTA updater" name might churn butter.
If the thing with the "OTA updater" name was a signed binary, things would not be as easy to modify as they are.
Not impossilbe to modify (when using binfmt_misc), just extra insurance that the binary was from a trusted source and intended for a specific Kindle make/model/firmware.
And the test would be made each time the load attempt was made.