Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MATLAB changes $LD_LIBRARY_PATH, breaks Qt apps #2965

Closed
3rdcycle opened this issue Jul 19, 2023 · 4 comments · Fixed by #2981
Closed

MATLAB changes $LD_LIBRARY_PATH, breaks Qt apps #2965

3rdcycle opened this issue Jul 19, 2023 · 4 comments · Fixed by #2981
Milestone

Comments

@3rdcycle
Copy link

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.

@boegel boegel added this to the 4.x milestone Aug 2, 2023
@boegel
Copy link
Member

boegel commented Aug 2, 2023

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...

@ocaisa
Copy link
Member

ocaisa commented Aug 2, 2023

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

@boegel
Copy link
Member

boegel commented Aug 2, 2023

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 boegel changed the title MATLAB changes LD_LIBRARY_PATH, breaks Qt apps MATLAB changes $LD_LIBRARY_PATH, breaks Qt apps Aug 2, 2023
@smoors
Copy link
Contributor

smoors commented Aug 4, 2023

i fully agree with this.

users should indeed just use the generated shell script to run the compiled executables, which correctly sets the LD_LIBRARY_PATH

./run_testmatlab.sh $EBROOTMATLAB &> testmatlab.out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants