Why Matlab R2019a does not recognize symbolic links under Linux RHEL 7.5?

I recently got an update of Matlab R2019a for Linux RHEL 7.5 (file system: Lustre 2.10.5.ddn2), and observed that Matlab does not recognize anymore symbolic links. In order to switch between different versions of Matlab I have written a small bash file that respectively creates symbolic links to pathdef.m and startup.m to select the associated Matlab version. However, this procedure breaks down under Matlab R2019a. If I apply the described procedure, then the links below

ls -l pathdef.m 
lrwxrwxrwx 1 yyyyyy uuu 16 26. Apr 19:11 pathdef.m -> pathdef.m_R2019a
ls -l startup.m
lrwxrwxrwx 1 yyyyyy uuu 16 26. Apr 19:11 startup.m -> startup.m_R1019a

produce the following failure:

matlab -nosoftwareopengl -nodesktop -nosplash


                                                                                            < M A T L A B (R) >
                                                                                  Copyright 1984-2019 The MathWorks, Inc.
                                                                                  R2019a (9.6.0.1072779) 64-bit (glnxa64)
                                                                                               March 8, 2019

Attempt to execute SCRIPT pathdef as a function:
/pfs/data1/home/kit/uuu/yyyyyy/matlab/pathdef.m
Warning: MATLAB did not appear to successfully set the search path. To recover for this session of MATLAB, type "restoredefaultpath;matlabrc". To find out how to avoid this warning the next time you start
MATLAB, type "docsearch problem path" after recovering for this session. 
Undefined function 'usejava' for input arguments of type 'char'.
Warning: MATLAB did not appear to successfully set the search path. To recover for this session of MATLAB, type "restoredefaultpath;matlabrc". To find out how to avoid this warning the next time you start
MATLAB, type "docsearch problem path" after recovering for this session. 
Warning: Initializing Java preferences failed in matlabrc.
This indicates a potentially serious problem in your MATLAB setup, which should be resolved as soon as possible.  Error detected was:
MATLAB:UndefinedFunction

When I remove the links while setting

ls -l pathdef.m
-rw-r--r-- 1 yyyyyy uuu 88619 26. Apr 19:17 pathdef.m
ls -l startup.m
-rw-r--r-- 1 yyyyyy uuu 2107 26. Apr 19:16 startup.m

Matlab R2019a is starting properly. However, I have to remove any link that is pointing to a Matlab function. For instance, I get the following issue

The anti-pre-kernel element of the game is given by:
aprk=Anti_PreKernel(bv)
Attempt to execute SCRIPT Anti_PreKernel as a function:
/pfs/data1/home/kit/uuu/yyyyyy/matlab/tugames_v0dot1b/Anti_PreKernel.m

Error in getting_started (line 77)
aprk=Anti_PreKernel(bv)

while setting a link to the Matlab function "Anti_PreKernel". Removing the link, and everything is running properly.

The anti-pre-kernel element of the game is given by:
aprk=Anti_PreKernel(bv)

aprk =

   22.6550   17.9050    7.3050   41.8600   37.1100   49.1650

Is there any workaround that avoids this strange behavior? Or is it a Lustre issue?

[Renaud GILLON]

I have the same problem. I am using links to allow to separate run directories from source directories. The original files reside in source directories. They are linked from the run directories, and I start MATLAB in the run directory to do the processing there.

Starting with version 2018b, I noticed that sometimes MATLAB would not recognize a script present in the current working directory, despite the fact that the link is there, and that versions before 2018b have no issue.

My impression the problem stems from the path cache feature. That one would resolve links and register MATLAB functions and scripts as being located at the link target file, instead of the link location. And then it issues a message "function/script not found in CWD, but somewhere else -- do you want to add the new location in the path" and then still the function is undefined.... Sounds like a big bug.

[Scott Frastaci]

Does anyone know if this problem has been fixed in R2020a or beyond?