Cannot build using snap version 13.0.2 because the environment is poluted with snap resource

[Levi-Armstrong]

The environment gets polluted with snap resources causing builds to fail because it is using libraries and other resource from snap locations instead of only using the system. I have not found any way to fix the issue. Paths to snap directories are showing up in LD_LIBRARY_PATH which I think is the is the main issue.

[christian-rauch]

Is the problem you are encountering essentially a mix of the libraries during compilation and execution?

I am encountering:

/usr/bin/ld: /snap/core20/current/lib/x86_64-linux-gnu/[LIBRARY]: undefined reference to `[SYMBOL]'
/usr/bin/ld: /lib/x86_64-linux-gnu/[LIBRARY]: undefined reference to `[SYMBOL]'

during compilation and:

[EXECUTABLE]: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/[LIBRARY]: undefined symbol: [SYMBOL]

at execution, e.g. of a ROS node.

[christian-rauch]

The issues with the "classic" Snap package format made me think about alternatives. I found that there are "experimental" Debian packages for Qt Creator (https://download.qt.io/official_releases/qtcreator/14.0/14.0.1/cpack_experimental/) and thought we could also generate a DEB package for the plugin that would work in tandem with this Qt Creator DEB package.

I started PoC work on this at #515. After you install the qtcreator-opensource-linux-x86_64-14.0.1.deb and ROSProjectManager-14.1-Linux-x86_64.deb manually, you should be able to start Qt Creator via /opt/qt-creator/bin/qtcreator and see in the details of the ROSProjectManager plugin in the plugin overview, that the path is /opt/qt-creator/lib/qtcreator/plugins/libROSProjectManager.so.

The plugin DEB package will depend on a specific major version of the Qt Creator DEB package so we can make sure that it stays ABI compatible. We can also generate DEB packages with debug symbols (*.ddeb) to simplify debugging and generating backtraces. The downside is that these DEB package files have to be downloaded and installed manually.

That do you think about going back to DEB packages?

[Levi-Armstrong]

Actually I decided to go through the process of installing Qt Creator from Qt and then using the plugin import where I provided it the zip file I downloaded from the archive which worked. Is there a reason not to just use this as the default?

[christian-rauch]

Is there a reason not to just use this as the default?

Installing Qt Creator with the official installer requires a Qt account, that some may not want to create just to install something that is open source. With a non-commercial licence, you have to check I'm an individual and do not use Qt for any company (https://www.youtube.com/watch?v=OoVNt-KJ96w&t=175s). While this only applies to the Qt library and not Qt Creator, this can be confusing and put people off.

Also, Qt Creator installed with the online installer will notify the user about updates. While it's fine to install the minor and patch versions, a major update will break the plugin API without notice. Since it is not possible to roll back these updates, a user will then be left with broken ROS support until a new plugin is released.

Essentially, I would like to have a way to distribute Qt Creator with the matching plugin such that you do not need an extra account and that Qt Creator and the ROS plugin are updated synchronously.

[Levi-Armstrong]

Makes sense. I like the debian approach.