Remove libQt5*.so.5 libs that are missing from the actual toolchain

[matteodelabre]

It looks like the current rM-provided toolchain, and the current rM system, do not include all of Qt’s libraries (e.g. libQt5Widgets.so.5, see toltec-dev/toltec#83.) This causes builds to succeed, but failing binaries due to missing dynamic libs on the device. We should remove those libs from the qt image.

[Eeems]

That or convince reMarkable to add them back.

[matteodelabre]

Right. But if I had to guess I’d say they removed it to save space on the root partition, since xochitl does not use that lib. Therefore they’re unlikely to add it back.

[Eeems]

Very likely. I've opened HiroshiTamura/1bitpaint_for_reMarkable#2 to get 1bitpaint updated to stop using it.

[matteodelabre]

List of Qt libs that are in Toltec’s qt image but not on the reMarkable:

/usr/lib/libQt5Bluetooth.so.5.11.3
/usr/lib/libQt5Charts.so.5.11.3
/usr/lib/libQt5Gamepad.so.5.11.3
/usr/lib/libQt5Help.so.5.11.3
/usr/lib/libQt5Location.so.5.11.3
/usr/lib/libQt5Multimedia.so.5.11.3
/usr/lib/libQt5MultimediaWidgets.so.5.11.3
/usr/lib/libQt5NetworkAuth.so.5.11.3
/usr/lib/libQt5Nfc.so.5.11.3
/usr/lib/libQt5Positioning.so.5.11.3
/usr/lib/libQt5PositioningQuick.so.5.11.3
/usr/lib/libQt5PrintSupport.so.5.11.3
/usr/lib/libQt5Purchasing.so.5.11.3
/usr/lib/libQt5QuickWidgets.so.5.11.3
/usr/lib/libQt5RemoteObjects.so.5.11.3
/usr/lib/libQt5Script.so.5.11.3
/usr/lib/libQt5ScriptTools.so.5.11.3
/usr/lib/libQt5Scxml.so.5.11.3
/usr/lib/libQt5Sensors.so.5.11.3
/usr/lib/libQt5SerialBus.so.5.11.3
/usr/lib/libQt5SerialPort.so.5.11.3
/usr/lib/libQt5Sql.so.5.11.3
/usr/lib/libQt5TextToSpeech.so.5.11.3
/usr/lib/libQt5WebChannel.so.5.11.3
/usr/lib/libQt5WebView.so.5.11.3
/usr/lib/libQt5Widgets.so.5.11.3
/usr/lib/libQt5XmlPatterns.so.5.11.3

[Eeems]

Would we be able to include some of these in a package under /opt? That's a potentially better alternative.

[matteodelabre]

Yes, it’s also a valid possibility.

[matteodelabre]

Would we be able to include some of these in a package under /opt? That's a potentially better alternative.

Thinking again about this. Currently, libraries in the rM root system link to the libc/libpthread/ld.so system libraries located in /lib, whereas libraries from Entware in /opt link to their own set of system libs located in /opt/lib. This situation makes it difficult (impossible?) to link a binary to both libraries from the rM root and from Entware. Therefore, if we were to install extra Qt libs, they would need to be linked to the system libs in /lib so that they can be used in conjunction with existing libs in /usr/lib. But then it would be inconsistent to put them under /opt/usr/lib, since libraries in that folder link to /opt/lib.

I can think of several possible solutions to this:

1. Completely ignore libraries from the rM root system and install a full Qt distribution in /opt.
2. Install extra Qt libs directly in /usr/lib and not under /opt.
3. Patch Entware libraries to link against system libs in / (could break on system update).
4. Patch rM libs to link against system libs in /opt (not a good idea).

[Eeems]

Completely ignore libraries from the rM root system and install a full Qt distribution in /opt.

This might be preferable. That way they continue to work if a system upgrade removes portions of the library again.

[matteodelabre]

This is indeed the most robust and flexible option IMO (resilient to system upgrades and we get to include the libs we want). I’m leaning towards this solution. Any thoughts @raisjn @LinusCDE?

[LinusCDE]

I would be fine with it. Developer could probably either take advantage of our libs with toltec or, for a standalone non-toltec release, ship a statically compile binary. This should make both options, a dev would probably like to do, independent of official system updates.

[matteodelabre]

Fixed in v1.4.