GLIBCXX Version Compatible Help

[Leo365]

I'm compiling some app for KPW1 on Debian Jessie, the default TC has a GLIBCXX version 3.4.20, as show:

Leo@Leo:~$ strings /usr/lib/arm-linux-gnueabi/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_DEBUG_MESSAGE_LENGTH

But KPW1 only support up to GLIBCXX_3.4.14, when I run the app in KPW1, it throws exceptions like 'GLIBCXX_3.4.20 not found'.

How can I solve this problem? It has troubled me for a long time.

[brianinmaine]

Originally Posted by Leo365

I'm compiling some app for KPW1 on Debian Jessie, the default TC has a GLIBCXX version 3.4.20, as show:

Leo@Leo:~$ strings /usr/lib/arm-linux-gnueabi/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_DEBUG_MESSAGE_LENGTH

But KPW1 only support up to GLIBCXX_3.4.14, when I run the app in KPW1, it throws exceptions like 'GLIBCXX_3.4.20 not found'.

How can I solve this problem? It has troubled me for a long time.

why not try a wheezy chroot?

[knc1]

And if that is not an exact match -
build the appropriate toolchain/glibc combination yourself (using any one of the many tools for the build process);
or
use the toolchain Niluje supplies in this forum (see his "snapshots" thread).

- - - -

Or, see my thread on using a completely different set of system libraries (hard float in the example case) for applications, **concurrently** with the Amazon installed libraries.
(my ARMHF on Kindle thread).
Yes, Linux (or any OS that uses elf format libraries) can do that - use more than one set of system libraries **concurrently**.


That example used Buildroot(.org) to build the toolchain and applications.
Since then, the BR people have even added the building of patchelf for your host machine to the BR system.

[NiLuJe]

See also my answer on GH .

As knc1 said, I'd strongly opt for a custom TC, since you're likely to eat dirt on myriad other weird and interesting ABI mismatches otherwise. There's already a whole section dedicated to that in the KOReader Makefile, as well as in my buildscript .

As I mentioned on GH, I'm a ct-ng fan, and as knc1 mentioned, my configs are up; but BR probably does the job perfectly well too, if you can get it to use the required fairly ancient glibc version (not as well versed in the panel of choices available on BR).