What is LD_LIBRARY_PATH when setting up matlab?

Hi,

When I setting up the environment variables, there is a variable named LD_LIBRARY_PATH that must be set to be able to run matlab.

How is this LD_LIBRARY_PATH is used in matlab? What is LD_LIBRARY_PATH trying to set for matlab?

Edit:

1. If I change those paths in LD_LIBRARY_PATH, what will happen? Will Matlab version change?

2. It seems like the LD_LIBRARY_PATH is setting 4 paths to 4 shared libraries for matlab, what are those libraries for?

3. If I have multiple installs of Matlab on my system, what should I do to change between different version of Matlab?

Thank you.

Answer 1

[Walter Roberson]

LD_LIBRARY_PATH is a standard UNIX (POSIX) environment variable that affects the directories searched by the linker at run-time to locate shared objects (.so) that were coded with a relative path instead of with an absolute path. It's behaviour is not specific to MATLAB, and MATLAB cannot control its behaviour (other than to change the contents of the environment variable.)

MATLAB has one or more directories that contains the shared objects that it uses, and it sets up LD_LIBRARY_PATH to refer to those directories, so that the linker knows where to look for the objects.

It is the run-time equivalent of the linker -L flag . At link time, the linker looks for shared objects in the -L directory list, and examines their symbol tables to create a translation list, but the list is not filled in with actual addresses. Then, at run time, the linker (exec) looks for libraries with the same names in the directories determined by the hard coded paths and by LD_LIBRARY_PATH, finds the shared objects with the matching name, looks up the implementation offset for each of the symbols, and fills in the translation table with the base virtual address for the library plus the symbol offset. Once that is done, the executable can read or write to those virtual addresses (for data) or call into the functions at those addresses. All standard operation of the way that code is executed on Unix-type systems.

When you system() out you might find that LD_LIBRARY_PATH has been set to refer to MATLAB directories. But sometimes the executables you are trying to invoke need a different version of a library with the same name -- for example MATLAB might have a libC.so on its LD_LIBRARY_PATH and the executable might need a different (newer) libC.so . In such a case, you might need to setenv() the LD_LIBRARY_PATH before the system(), or you might need to have the command being system()'d change the LD_LIBRARY_PATH

[Kim Ngan Nguyen]

Thank you for the answer. I have 3 follow up questions:

1. If I change those paths, what will happen? Will Matlab version change?

2. It seems like the LD_LIBRARY_PATH is setting 4 paths to 4 shared libraries for matlab, what are those libraries for?

3. If I have multiple installs of Matlab on my system, what should I do to change between different version of Matlab?

Thank you

[Walter Roberson]

1) You need to be clear about the time that LD_LIBRARY_PATH is coming into use.

If you set LD_LIBRARY_PATH before you start MATLAB, then that potentially has an effect on where MATLAB searches for the shared objects it uses. The search for symbols will take the first library on the path that has a matching name and which matches any version number constraints. So for example if you change the LD_LIBRARY_PATH that is used to find libC.so then MATLAB would potentially use a different one than its own version . The MATLAB executable would not be permanently changed, but for that session the operating system would use whichever version of the shared object it found first during the search.

If you set LD_LIBRARY_PATH using the MATLAB setenv() command, then that will affect any future calls to the shell using system() or the ! command, but will not affect where MATLAB itself looks for shared objects if I recall correctly (I could be wrong about this point, for the situation where MATLAB does dynamic link to an object, such as for loadlibrary() purposes.)

If you set LD_LIBRARY_PATH inside a system() or ! command, then the change will be temporary, only for as long as that shell lasts. Example,

!export THISTHISTHIS=THATTHATTHAT; echo "$THISTHISTHIS"

THATTHATTHAT

!echo "$THISTHISTHIS"

it existed for that one ! session and is gone for the next !

In either case, setenv() before system() or ! or setting the path inside system() or ! command, executables that are invoked in the shell are affected by whatever you set up.

2)

LD = getenv('LD_LIBRARY_PATH');
LDparts = regexp(LD, ':', 'split').'

LDparts = 15×1 cell array
    {'/MATLAB/sys/opengl/lib/glnxa64'                                        }
    {'/MATLAB/sys/os/glnxa64'                                                }
    {'/MATLAB/bin/glnxa64/mvm'                                               }
    {'/MATLAB/bin/glnxa64'                                                   }
    {'/MATLAB/extern/lib/glnxa64'                                            }
    {'/MATLAB/cefclient/sys/os/glnxa64'                                      }
    {'/MATLAB/runtime/glnxa64'                                               }
    {'/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre/lib/amd64/native_threads'}
    {'/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/jre/lib/amd64/server'        }
    {'/usr/bin/gcc-8.3.0/lib64'                                              }
    {'/usr/local/cuda/lib64'                                                 }
    {'/usr/local/nvidia/lib'                                                 }
    {'/usr/local/nvidia/lib64'                                               }
    {'/usr/local/cuda/lib64/stubs'                                           }
    {0×0 char                                                                }

14 paths are set. Let's see what is in the first one

ls(LDparts{1})

C11ThreadEmulationLibraryLicense.rights  GalliumCodeLicense.rights    libGL.so.1      libGLU.rights  libGLU.so.1.3.1		      MesaLicense.rights
EXTHeaderLicense.rights			 GLXClientCodeLicense.rights  libGL.so.1.6.0  libGLU.so.1    MesaDeviceDriversLicense.rights

Those libraries are requried by OpenGL

ls(LDparts{2})

libgcc_s.so.1	  libgfortran.so.5.0.0	libifport.so.5	libintlc.so.5  libirc.so	 libquadmath.so.0.0.0  libstdc++.so.6.0.28  orig
libgfortran.so.5  libifcore.so.5	libimf.so	libiomp5.so    libquadmath.so.0  libstdc++.so.6        libsvml.so	    README.libgcc_s

That is some Fortran runtime-libraries, and also mathematics libraries (some of the math libraries are implemented in Fortran)

ls( '-l', LDparts{3})

total 68
lrwxrwxrwx 1 root root    13 Sep 13 13:16 icudtl.dat -> ../icudtl.dat
-r-xr-xr-x 1 root root 68688 Aug  5 00:34 MATLAB
lrwxrwxrwx 1 root root    19 Sep 13 13:16 natives_blob.bin -> ../natives_blob.bin
lrwxrwxrwx 1 root root    20 Sep 13 13:16 snapshot_blob.bin -> ../snapshot_blob.bin

That has to do with Unicode translation

... and so on.

3) Typically you let MATLAB manage its own path. The executable you name to start up on Linux is, if I recall, a shell script that sets up the environment variables and then starts the binary. If you have reason to manage LD_LIBRARY_PATH or other setting (such as Java Library location) then there are various routes available, such as building you own scripts, or modifying the GUI launch settings, or using system-specific methods of permanently modifying your environment variables.

But typically you would not manage the situation by editing the user's login shell startup scripts: when a script is launched from your window manager, that is typically not considered a "login" to the shell, so most shell startup scripts do not get executed.

[Kim Ngan Nguyen]

Thank you so much for the detailed answer!