Closed leamas closed 4 years ago
BTW: How is libsgllnx64-2.29.02.so obtained? Have you a pointer to the sources?
Final note: libsgllnx64-2.29.02.so depends on libusb-0.1.so.4. This is strange, both latest upstream and the usually bleeding edge Fedora are on libusb-0.1.so.0. Perhaps the simplest solution would be to rebuild libsgllnx64 against thisi version which seems stable and generally available?
EDIT: libusb-0.1.so.4 is not strange, it's readily available from upstream (version 0.1.5). Thus: the libusb dependency is not a problem..
Alec... We do not have access to the build source for libsgllinx. It is a private library required for our USB dongle, supporting a DCM protocol. At the moment, it is what it is, although we are working with upstream to try to improve cross-platform compatibility.
Do I understand that all is well if we adopt your patch?
It is a private library required for our USB dongle
OK, I understand.
Do I understand that all is well if we adopt your patch?
Not yet... more testing needed. I'm on it.
Last bit fixed with #65. Thanks for your efforts on this, most of which not visible on github.
This is seen on the flatpak build, perhaps also on others.
The library libsgllnx64-2.29.02.so which lives under buildlinux64 is not included in the tarball, and thus missing in runtime. The symptoms are as described in #48. There is also lot's of console output about the missing, not found library.
Manually adding it resolves the first error and reveals a new: libsgllnx64-2.29.02.so depends on libusb-0.1.so.4 which is not generally available (outdated). We need to provide also this (or rebuild libsgllnx against a newer distro).
libusb does not seem to have any specific runtime deps.