Repository: easybuilders/easybuild-easyblocks

Issue:
MATLAB changes `$LD_LIBRARY_PATH`, breaks Qt apps
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](https://www.mathworks.com/help/compiler/mcr-path-settings-for-run-time-deployment.html) 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.





Discussion:
I've seen other cases where the libraries shipped by MATLAB cause trouble (for [DecOT](https://github.com/lg-ustb/DecOT), which depends on [MATLAB-Engine](https://www.mathworks.com/help/matlab/matlab-engine-for-python.html)), 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...
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` 

```bash
./run_testmatlab.sh $EBROOTMATLAB &> testmatlab.out
```

Resolving patch:
diff --git a/easybuild/easyblocks/m/matlab.py b/easybuild/easyblocks/m/matlab.py
--- a/easybuild/easyblocks/m/matlab.py
+++ b/easybuild/easyblocks/m/matlab.py
@@ -221,11 +221,6 @@ def make_module_extra(self):
         """Extend PATH and set proper _JAVA_OPTIONS (e.g., -Xmx)."""
         txt = super(EB_MATLAB, self).make_module_extra()
 
-        # make MATLAB runtime available
-        if LooseVersion(self.version) >= LooseVersion('2017a'):
-            for ldlibdir in ['runtime', 'bin', os.path.join('sys', 'os')]:
-                libdir = os.path.join(ldlibdir, 'glnxa64')
-                txt += self.module_generator.prepend_paths('LD_LIBRARY_PATH', libdir)
         if self.cfg['java_options']:
             txt += self.module_generator.set_environment('_JAVA_OPTIONS', self.cfg['java_options'])
         return txt


Test patch: