Loading of Foreign Libraries Is Not Proper When Starting a Deployed Binary

[Shinmera]

It seems that when additional foreign libraries are included in the project that aren't part of Qt itself, the load order on startup might not be proper, causing some libraries to fail entirely. This has to be fixed, either by making the process smarter, or by allowing the user to hook into it and provide their own load mechanism that ensures correct behaviour.

[kostafey]

That means I can't make executable via sb-ext:save-lisp-and-die or ccl:save-application?

[Shinmera]

You can, but it won't work on deployed systems due to the way shared libraries are discovered. If your system only uses the Qt libraries and no other, you can however use Qtools' deployment system to make it deliverable. For this, modify your ASDF system like so:

(asdf:defsystem :my-system
  ...
  :defsystem-depends-on (:qtools)
  :build-operation "qt-program-op"
  :build-pathname "my-executable-name"
  :entry-point "my-package:my-launch-function")

After this, simply run sbcl --eval '(asdf:operate :build-op :my-system)' and it should generate a deployable folder within your project root.

What this issue is about is that additional shared libraries that are not part of Qt don't get properly deployed in this process.

[kostafey]

This helps to make executable, thank you!

But I still can use libraries entirely written on Common Lisp, the restriction is only for FFI libraries?

[Shinmera]

Yes of course. The problem is only related to .so/.dll/.dylibs.

[kostafey]

Thank you very much! I'm just styding CL and CommonQt but if I can help with testing, please notice me.

[Shinmera]

As of 7be76d1f41e8c6e4e447b5b0e18e1d05224fe1af this is now fixed.