Koreader (CoolReader) GLIBC_2.11 error in Kindle 3

[abbaspour]

Hi all,

I got the Koreader (Lua bit) working on my Kindle 3 (keyboard). But when trying load file an ePub into reader (libkoreader-cre) it fails with GLIBC_2.11 dependency.

Here is the application log when I ssh and run:


root@kindle koreader# ./reader.lua -d /mnt/us/documents/book.epub
# initializing for device Kindle3
# show reader ui
# show widget
Warning: Could not load rt.so, falling back to gettimeofday.
# opening file /mnt/us/documents/book.epub
# cannot open document /mnt/us/documents/book.epub error loading module 'libs/libkoreader-cre' from file './libs/libkoreader-cre.so':
/lib/libc.so.6: version `GLIBC_2.11' not found (required by /mnt/us/koreader/./libs/libcrengine.so)



Looking at the library with readelf, I can use some longjmp methods from GLIBC 2.11:



$ readelf -Ws koreader-arm-linux-gnueabi/koreader/libs/libcrengine.so | grep GLIBC_2.11
14: 00000000 0 FUNC GLOBAL DEFAULT UND __longjmp_chk@GLIBC_2.11 (7)



I tried to compile with static linking against glibc (-static-libgcc) but that one didn't help too.

Tried with 4.8 on Ubuntu 12.04 and Mint 17.1 (= Ubuntu 14.04 trusty)

Source is compiled with undefined FORTIFY and _GNU_SOURCE

Any help highly welcomed.

[NiLuJe]

@abbaspour: That's because there's a specific target for the older devices (kindle-legacy) which enables some more trickery to tame down the TC. Also no real guarantee that everything works properly on devices without a touchscreen, hence the lack of official release (cf. kpdfviewer instead)

Note that this was last tested with a fairly not-so-recent MG toolchain, it might not be enough for a bleeding edge TC; see the comments in the Makefiles.

And that my own tests were made (again, long ago) with a TC built against glibc 2.9, so, I obviously never ran into that one .

[knc1]

How does that behavior compare with that of Libreator?
https://www.mobileread.com/forums/sho...d.php?t=198742
(Which is KOReader, ported to keyboard devices.)

[NiLuJe]

Note that the _chk variants of longjmp come from <bits/setjmp2.h>, which definitely shouldn't be included if __USE_FORTIFY_LEVEL is 0 (i.e., -U_FORTIFY_SOURCE).

It's been a while since I meddled with KO's buildsystem, but there might be some parts of the build that don't yet honor every flag we enforce, in which case, if you can pinpoint the root issue, send a PR on GH.

That said, a cursory glance at the Makefile doesn't reveal anything wonky on that front for crengine...

Double check how your're setting your *FLAGS, and the sanity of the headers of your TC. I'm guessing you weren't using the kindle-legacy target?


@knc1: Technically, it's a fork of the ancestor of KOReader, kindlepdfviewer .

[knc1]

Note -
If you can't build against the older glibc version used on the K3, then take a look at running more than one set of system libraries at the same time.

The "ARMHF on Kindle" has a worked example.
(Not that you need hard float, hard float is just used as a how-to run multiple system libraries on the same system, concurrently.)

[abbaspour]

thanks for the replies. I explicitly added "-U_FORTIFY_SOURCE" as CMAKE_CXX_FLAGS inside kpvcrlib CMakeLists.txt and the longjmp_chk disappeared. but still have dynamic linking error. this time with below error.

what you reckon? should I statically link against libstdc++ ?


# opening file /mnt/us/documents/book.epub
# cannot open document /mnt/us/documents/book.epub error loading module 'libs/libkoreader-cre' from file './libs/libkoreader-cre.so':
/usr/lib/libstdc++.so.6: version `CXXABI_ARM_1.3.3' not found (required by /mnt/us/koreader/./libs/libcrengine.so)

[NiLuJe]

@abbaspour:

Yup, -static-libstdc++

But, again, that should be the default (https://github.com/koreader/koreader...file.defs#L193 && https://github.com/koreader/koreader...efile.defs#L86).
And it's explicitly always done for cre, AFAICT (https://github.com/koreader/koreader.../Makefile#L288 && https://github.com/koreader/koreader.../Makefile#L187).

So, err, again, make sure nothing in your env is polluting *FLAGS or that you're not overriding them by passing them to make on the CLI.

As you can see, the Makefiles are a house of cards tailored to the buildbot and the envs of a few developers, I've always directly messed w/ Makefiles.defs when I needed to adapt stuff to my TC, that's the safest move.

(Also, you shouldn't have had to mess with cmake's rules for cre).