toolchain v1.3+ build of rm2fb crashes koreader

[snelg]

Not sure which project is causing the problem, but here's the situation:

The last rm2fb release was on January 3, so it was built with toltec-dev/qt image v1.2.1.
As I was working on some tweaks for rm2fb, I found that building it with image v1.3 and above can cause koreader to crash on startup.
After testing a bit, I figured out that the startup crash is consistent, but only on a fresh koreader install.
After testing a lot I figured out that the pertinent difference in a fresh install is that there's no existing font cache, so koreader tries to build it. The ffi lua code calls out to libs/libharfbuzz.so.0, and somewhere in there it crashes.
That's as far down as I know how to dig.

[Eeems]

Sounds like we might want to add a hook to the package to build the cache using the correct tooling?

Which device(s) is this happening on?

[snelg]

This is on a reMarkable 2.

[NiLuJe]

Is anything else in KOReader's address space perhaps pulling in a different harfbuzz version (via unfortunate DT_NEEDED entries)?

(e.g., check /proc/$pid/maps).

EDIT: Or, worse, bundling a static copy of HB?

[NiLuJe]

Looking at the lddtree output on rm2fb, it pulls in QtCore (which, okay, I guess) and QtGui. It's conceivable that QtGui itself will pull in HB (it certainly does on my desktop ;p).

A few questions:

• Does rm2fb really need to link against Qt5Gui?
• Is everything linked w/ --as-needed? What GCC + binutils versions are used? (as-needed appears to be slightly broken on binutils > 2.34 with "older" GCC versions on my end).
• Are there rpath/LD_LIBRARY_PATH set to ensure nothing gets too wonky on that front?

[NiLuJe]

And since I've now read ddvk/remarkable2-framebuffer#52 and in particular @matteodelabre's tests (thanks!), I would assume that it is indeed an rpath somewhere that's screwing the pooch.

(An rpath takes precedence over LD_LIBRARY_PATH, c.f., man ld.so).

[NiLuJe]

Whether rm2fb actually needs to link to Qt5Gui is still relevant, though, as this kind of stuff is bound to wreak havoc on other non-Qt rm2fb users ;).

[Eeems]

Whether rm2fb actually needs to link to Qt5Gui is still relevant, though, as this kind of stuff is bound to wreak havoc on other non-Qt rm2fb users ;).

https://github.com/ddvk/remarkable2-framebuffer/blob/master/src/client/main.cpp#L16 Looks like no, looks like the client only uses QByteArray

Likely https://github.com/ddvk/remarkable2-framebuffer/blob/master/src/client/client.pro just needs to have QT -= gui like https://github.com/Eeems/oxide/blob/master/applications/screenshot-tool/fret.pro#L1

[matteodelabre]

Dynamic section of a working rm2fb build (made with the reMarkable toolchain):

  NEEDED               librt.so.1
  NEEDED               libdl.so.2
  NEEDED               libQt5Core.so.5
  NEEDED               libpthread.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-armhf.so.3
  SONAME               librm2fb_client.so.1

Dynamic section of a rm2fb build that crashes KOReader (made with the latest Toltec toolchain):

  NEEDED               librt.so.1
  NEEDED               libdl.so.2
  NEEDED               libQt5Gui.so.5
  NEEDED               libQt5Core.so.5
  NEEDED               libpthread.so.0
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-armhf.so.3
  SONAME               librm2fb_client.so.1
  RPATH                /usr/lib

This is probably due to differing global Qt configurations between the two toolchains. Thanks for putting me on the right track @NiLuJe!

[NiLuJe]

So, an extra DT_NEEDED on Qt5Gui and a DT_RPATH ;p.

While I'm somewhat wary of such a generic RPATH as a general rule (especially one that points to a default searchpath), that's probably a question better left answered by the toltec org (e.g., whether it's really necessary and why, and/or if a RUNPATH would be less invasive if such a thing really is necessary).

But as far as rm2fb and the issue at hand is concerned, getting rid of Qt5Gui ought to be enough, and @Eeems' proposal in #8 (comment) should do the trick ;).

[NiLuJe]

And on the subject of toolchains, usual reminder that as-needed saves lives, especially in C++-land ;).

(Keep in mind my comment above about it currently being wonky in some configurations, though).

[matteodelabre]

Fixed in ddvk/remarkable2-framebuffer#53. The next toolchain version will have Qt’s rpath option disabled by default: it’s not useful to set rpath on generated binaries since the Qt libs are already in the system library path on the device. I have decided not to change the default configuration to exclude the GUI library for the time being, so as to not deviate too much from the default Qt configuration.