Download and install not clean on Ubuntu 20.04.1 LTS

[matsc-at-sics-se]

The shared objects in lib/ cause some clashes and interferes with installed software (emacs), and fzn-gecode-gist does not work. Behavior if LD_LIBRARY_PATH does not include lib/:

$ echo $QT_PLUGIN_PATH
/opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/plugins
$ echo $LD_LIBRARY_PATH
/usr/local/lib
$ emacs
$ fzn-gecode-gist -mode gist ./tests/fcts/globals/sort.fzn
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

Aborted (core dumped)

Behavior if LD_LIBRARY_PATH includes lib/:

$ echo $QT_PLUGIN_PATH
/opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/plugins
$ export LD_LIBRARY_PATH=/opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/lib:/usr/local/lib
$ emacs
emacs: symbol lookup error: /usr/lib/x86_64-linux-gnu/librsvg-2.so.2: undefined symbol: cairo_tag_end
$ fzn-gecode-gist -mode gist ./tests/fcts/globals/sort.fzn
fzn-gecode-gist: /opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5)

[matsc-at-sics-se]

And here is how the shared objects break git on Ubuntu 20.04. It took me hours to understand what was going on:

$ LD_LIBRARY_PATH=/opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/lib git fetch
fatal: unable to access 'https://github.com/LuddeWessen/YuMiSequencer-MiniZinc/': Error -50 setting GnuTLS cipher list starting with +VERS-TLS1.3
$ LD_LIBRARY_PATH= git fetch
Username for 'https://github.com': ... [working]

[Dekker1]

TLDR; to prevent libraries in the distribution from interfering with your other installed packages it is best to sandbox the MiniZinc execution. The easiest option for this is to use the AppImage, which will load the libraries in the correct order at runtime. (As described in the documentation you can use it for command line minizinc as well by symlinking it with the right name.)

Hi Mats,

With the tarball distribution of MiniZinc we ship all required libraries apart from base system libraries (such as glibc). This means that for most bare linux distribution you can add these libraries to the loader path and execute MiniZinc. We don't test for all distributions, but we expect this to work on most of them.

It is not, however, expected that you can just add these libraries to the loader path permanently or just install MiniZinc to /usr/local/. As you mentioned, this can interfere with the libraries installed by the operating system. We cannot prevent this from happening as there are so many (versions of) distributions that it would be impossible to find library versions that are compatible with all of them.

The idea behind the distribution instead would be to temporarily load the libraries whenever you use MiniZinc. This way MiniZinc will be able to load the versions of the libraries it expects without interfering with the programs that expect the MiniZincIDE.sh script that is provided in the distribution. In this script the loader path is changed for the process of the MiniZincIDE and a very similar script can be made for the minizinc executable.

In my opinion the best solution to this problem is to use the AppImage format. This is a self-contained executable that includes all libraries, similar to the .app format for MacOS. This means that when the program is started, the libraries contained in the AppImage are loaded. Normally executing the AppImage will start the MiniZincIDE, but for your convenience we have provided the functionality that when the AppImage is opened by the name minizinc it will act as the MiniZinc command line executable. This can easily be used by creating a symlink with the name minizinc which points to the AppImage.

The snap package acts in a very similar way, but is even more extreme. Here the whole execution context is replaced by a containerised version of Ubuntu.

Although it is not supported, you could try and use the MiniZinc libraries in the normal execution context. In this case I would suggest that you add the MiniZinc libraries to the end of the loader path. This will make sure that the MiniZinc libraries never interfere with the programs installed by the linux distribution, but this also means that if you have installed different version of the same library using your operating system that these libraries can interfere with MiniZinc. This means that MiniZinc will only work if the versions of these libraries are compatible with the versions that are used by MiniZinc (and its loaded libraries that are not installed on the operating system).

To really integrate directly with the libraries that your operating system uses MiniZinc would have to be build as a package in the package manager used by your operating system. Although this would be an ideal case, there are too many distributions to manage this from our side. We would however welcome contributions of people willing to maintain the building of MiniZinc for different linux distributions.

[matsc-at-sics-se]

Thank you Jip. I can manage the shared objects. But I can't make fzn-gecode-gist work, no matter how I juggle the shared objects, because of some Qt problem. Can you help me?

[Dekker1]

I'm afraid I'm not very familiar with how Qt works. I've experienced the issue you had in the past, but correctly setting the resource path solved that for me. Maybe @cyderize would be better suited to help out with that issue.

[matsc-at-sics-se]

I had a look:

$ strings /opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/bin/fzn-gecode-gist | grep Qt_5
Qt_5
Qt_5.7

I guess that means that fzn-gecode-gist was compiled with headers for Qt 5.7. But Ubuntu 20.04 is set up for Qt 5.12. I don't think there is any way around that incompatibility by setting paths etc. The only way out that I see is to compile fzn-gecode-gist from source code with headers for Qt 5.12. That is what I will do when Gecode 6.3.0 is out.

Ubuntu 20.04 LTS will be supported until April 2025, longer than any other Ubuntu release. So, arguably, it deserves to be well supported.

[cyderize]

I think there may be some issues with fzn-gecode-gist requiring a Qt module that is not used in the IDE and therefore wasn't included in the bundle on Linux (that's the libQt5PrintSupport error - it's trying to use your system's library, but all the Qt libraries should have been included in the package). I think the way we build the IDE on Linux will have to be tweaked a little bit to include it.

Then at least setting up LD_LIBRARY_PATH to include the IDE's lib directory would allow Gecode Gist to work (but it would still conflict with other applications, so can't be set globally).

Using the Snap package avoids all these issues (although I don't think you can run fzn-gecode-gist from the command line in that case, you'd have to run it through the minizinc command, although I might be wrong about that).

[matsc-at-sics-se]

No, with LD_LIBRARY_PATH set up to include the IDE's lib directory, Gecode Gist still doesn't work:

$ LD_LIBRARY_PATH=/opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/lib MiniZincIDE
[...]
fzn-gecode-gist: /opt/MiniZincIDE-2.5.3-bundle-linux-x86_64/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5)

Perhaps it would have worked if you had included the right libQt5PrintSupport in the bundle.

[cyderize]

Yes, I've tried it with the proper libQt5PrintSupport in the bundle and it fixes the issue. Until this is properly fixed in the build system for the next release, it's possible to extract the required .so files from the libQt5PrintSupport .deb package and place them in the IDE's lib directory.

[matsc-at-sics-se]

Yes, it worked. I guess you can close the issue, with a note to fix it in the build system for the next release.
Many thanks!

[cyderize]

I've transferred this to the IDE repo since that's where the bundling happens. I'll close it when it's fixed in a release