You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been debugging an issue with an app that depends on the Qt5 module. The app won't start because it can't find Qt's platform plugins:
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
I wrote a minimal Qt app to find the cause of this and it turns out to be MATLAB. More specifically, the fact that the MATLAB module prepends LD_LIBRARY_PATH with $EBROOTMATLAB/bin/glnxa64, a directory that contains tons of bundled MATLAB libraries, including their own versions of essential Qt5 libraries and many other unrelated libs which could potentially interfere with other modules too.
This change was introduced in #2008, presumably to make it easier for MCR compiled apps to load. For MATLAB itself this does not seem to be necessary because the matlab startup script sets LD_LIBRARY_PATH and other required environment variables on invocation.
The MATLAB docs cautions (bottom of the page) against setting LD_LIBRARY_PATH permanently on Linux due to this interference risk with other software. They suggest to "run MATLAB Compiler applications using the generated shell script" instead.
I would propose to revert #2008 but would obviously like to hear @smoors and maybe other's opinion on this first.
The text was updated successfully, but these errors were encountered:
I've seen other cases where the libraries shipped by MATLAB cause trouble (for DecOT, which depends on MATLAB-Engine), so reconsidering the $LD_LIBRARY_PATH update makes sense to me...
Are we willing to run patchelf on the installation? You could use that to inject an rpath into the executables and libraries, removing the need to set LD_LIBRARY_PATH at all
I don't think that would help here, since the problem isn't so much with matlab itself (that can find its libraries just fine), but with compiled MATLAB programs that need to find the MATLAB runtime libraries.
Simply adding the path to those libraries to $LD_LIBRARY_PATH works, but is too big of a hammer, clearly...
boegel
changed the title
MATLAB changes LD_LIBRARY_PATH, breaks Qt apps
MATLAB changes $LD_LIBRARY_PATH, breaks Qt apps
Aug 2, 2023
I've been debugging an issue with an app that depends on the Qt5 module. The app won't start because it can't find Qt's platform plugins:
I wrote a minimal Qt app to find the cause of this and it turns out to be MATLAB. More specifically, the fact that the MATLAB module prepends
LD_LIBRARY_PATH
with$EBROOTMATLAB/bin/glnxa64
, a directory that contains tons of bundled MATLAB libraries, including their own versions of essential Qt5 libraries and many other unrelated libs which could potentially interfere with other modules too.This change was introduced in #2008, presumably to make it easier for MCR compiled apps to load. For MATLAB itself this does not seem to be necessary because the
matlab
startup script setsLD_LIBRARY_PATH
and other required environment variables on invocation.The MATLAB docs cautions (bottom of the page) against setting LD_LIBRARY_PATH permanently on Linux due to this interference risk with other software. They suggest to "run MATLAB Compiler applications using the generated shell script" instead.
I would propose to revert #2008 but would obviously like to hear @smoors and maybe other's opinion on this first.
The text was updated successfully, but these errors were encountered: