How to use system libcrypto.so.1.1 instead of MATLAB libcrypto.so.1.1 to avoid error: symbol EVP_KDF_ctrl version OPENSSL_1_1_1b not defined in file libcrypto.so.1.1

Since I work on a cluster and I'm not the admin, I simply cannot delete any files from the <MATLABROOT> folder. I wonder is there an alternative way, to block the particular file from MATLAB search path? Thanks.

The reason why I wanted to block a particular file from <MATLABROOT>, is because due to the parculiarity of the OS, Linux CentOS 8 (a RedHat variant of Linux), the existence of a file in <MATLABROOT> (that is, libcrypto.so.1.1) is having conflict with the OS system files, and the error reads:

Unable to load bundle binary /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/bin/glnxa64/builtins/shared_dastudio_builtins/mwdastudio_builtinimpl.so. Error:
/lib64/libk5crypto.so.3: symbol EVP_KDF_ctrl version OPENSSL_1_1_1b not defined in file libcrypto.so.1.1 with link time reference: Success

Although I found some other solutions such as this post or this other post, but the solution requires removing this particular file from <MATLABROOT>, to which I do not have the privilege. So I am thinking about the possiblity of blocking it within MATLB search path instead of deleting it. IS there a way this could work?

[Stephen23]

Have you checked if MATLABROOT is on the Search Path?

R = matlabroot()

R = '/MATLAB'

findstr(strcat(path(),':'),strcat(R,':'))

ans =

     []

I don't see any reason why it should be on the Search Path.

[Tong Zhao]

Hi Stephen, I have the following

R = matlabroot()
R =
    '/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6'

[Stephen23]

@Tong Zhao: please show the output of this command:

findstr(strcat(path(),':'),strcat(R,':'))

[Tong Zhao]

@Stephen Stephen, I have the following

findstr(strcat(path(),':'),strcat(R,':'))
ans =
     [] 

Ok, I got your point, so you're saying, the <MATLAB> root is not on my search path. So maybe let me ask this question instead: how to ensure that when I run a Simulink model in the MATLAB installed on the particular OS, a file 'MATLABROOT//bin/glnxa64/libcrypto.so.1.1' is not referenced, instead, the OS's own version of libcrypto.so.1.1 will be referenced?

Answer 1

[Tong Zhao]

I found an answer to my own problem, thanks to my cluster admin, and @Walter Roberson. And the solution turned out to be not exactly blocking a file from the search path, but adding the system dll / so files to the LD_PRELOAD environment variable before running matlab. So I will change the question title from

"How to block a file from MATLAB search path" to "How to use system libcrypto.so.1.1 instead of MATLAB libcrypto.so.1.1 to avoid error symbol EVP_KDF_ctrl version OPENSSL_1_1_1b not defined in file libcrypto.so.1.1"

Here's the workaround solution that worked for me:

in the linux terminal, do:

export LD_PRELOAD=/usr/lib64/libcrypto.so.1.1

before the MATLAB run.

What this does, as it seems to me, is that it prioritizes libraries that it specifies, which is exactly what I needed.

Answer 2

[Walter Roberson]

In Linux, it is not possible for a non-privileged process to disable using an individual dll in a directory that it does not have write access to.

You must either get the cluster administrator to delete the file, or else you need to create a copy of the directory that omits the dll and change LD_LIBRARY_PATH to have the new dll instead of the other. (Changing LD_LIBRARY_PATH is ignored for suid or sguid processes, but matlab is not either of those.)

[Tong Zhao]

Thank you Walter. I think you understood my issue. I have very little confidence that the cluster admin will delete a file from MATLABROOT just for me. Your second suggestion is worth a try. But for re-assigning the LD_LIBRARY_PATH, I have a further question: do I also need sudo privilege to change it? If I don't need sudo, what should I do to change it. I have:

echo $LD_LIBRARY_PATH
/cm/shared/apps/slurm/current/lib64/slurm:
/cm/shared/apps/slurm/current/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib

(I separated the paths line by line myself)

And my MATLABROOT is at:

/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6

Seems my MATLABROOT is not even on LD_LIBRARY_PATH. For the other environment variable $LIBRARY_PATH it has the same list of paths. So does that mean I'm looking at the wrong environment variable? I don't know how the MATLABROOT path is being referenced during the Simulink call. My full lines of code once I enter MATLAB terminal is the following:

% loading the Simulink.SimulationInput object stored in variable 'in'
load('simIn.mat'); 
% perform parallel simulations
out = parsim(in, 'ShowProgress', 'on');
% save the results
save('simOut.mat','out');

[Walter Roberson]

https://stackoverflow.com/questions/4250624/ld-library-path-vs-library-path

You are Runtime so you can ignore LIBRARY_PATH

I would not expect matlabroot() to appear on the library path: I would expect a subdirectory of it to appear. Unless, that is, the dll are in the exact same directory as the matlab executable itself. The matlab executable is in bin/archa or something like that relative to matlabroot()

As an experiment, start matlab and in MATLAB

getenv('LD_LIBRARY_PATH')
! echo "$LD_LIBRARY_PATH"

and show us the results

[Tong Zhao]

Hi @Walter Roberson Walter,

my matlab executable is at <MATLABROOT>/bin/matlab, and the dll file (.so file in Linux terms) is at <MATLABROOT>/bin/glnx64/ . So in a way, the dll (or .so) file is in a folder next to the matlab executable.

And after running the following in matlab terminal

getenv('LD_LIBRARY_PATH')

I got:

ans =

    ['/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/opengl/lib/glnxa64:' ...
        '/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/os/glnxa64:' ...
        '/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/bin/glnxa64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/extern/lib/glnxa64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/cefclient/sys/os/glnxa64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/runtime/glnxa64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/server:' ...
        '        /cm/shared/apps/slurm/current/lib64/slurm:' ...
        '/cm/shared/apps/slurm/current/lib64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib64:' ...
        '        /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib']

and runing the !echo command inside matlab:

!echo "$LD_LIBRARY_PATH"
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/opengl/lib/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/os/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/bin/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/extern/lib/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/cefclient/sys/os/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/runtime/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/server:
/cm/shared/apps/slurm/current/lib64/slurm:
/cm/shared/apps/slurm/current/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib
>>

While running the echo command outside of matlab:

/cm/shared/apps/slurm/current/lib64/slurm:
/cm/shared/apps/slurm/current/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib

OK, I see that when matlab is running, the folder <MATLABROOT>/bin/glnxa64 is included in LD_LIBRARY_PATH, but when matlab is not running, it is not in LD_LIBRARY_PATH. So do you suggest that I remove the folder <MATLABROOT>/bin/glnxa64 from LD_LIBRARY_PATH while running matlab? If so, how can I do that? Maybe this will also fail because by excluding the /bin/glnx64 folder from LD_LIBRARY_PATH, I'm effectively excluding all the dll (or .so) files from my MATLAB search path. And my program may not be able to run due to this. This is just my guess.

[Walter Roberson]

You would use getenv() to fetch the current value, edit it, setenv() the new value.

Remember what I said about a copy of the directory that omits the dll. You could probably prepare that ahead of time.

The echo was, by the way, intended to be executed within matlab. The ! is a matlab command that is a shortcut for system()

[Tong Zhao]

@Walter Roberson:

Thanks for the heads up. I did make a copy of the `glnx64` folder to another destination `\home\zhao1991\glnx64new\`, deleted libcrpyto.so.1.1 in the new folder, and replaced the old reference in LD_LIBRARY_PATH with the new one, now the environment variable is:

!echo "$LD_LIBRARY_PATH"
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/opengl/lib/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/os/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/extern/lib/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/cefclient/sys/os/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/runtime/glnxa64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/sys/java/jre/glnxa64/jre/lib/amd64/server:
/cm/shared/apps/slurm/current/lib64/slurm:/cm/shared/apps/slurm/current/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib64:
/cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/gcc-10.2.0-n7su7jf54rc7l2ozegds5xksy6qhrjin/lib:
/home/zhao1991/glnx64new/

The last entry is the new folder location.

Then I tried running the same matlab program again, and it still shows the same error, shall I rehash the matalb system reference somehow? Is there some form of cache that is still finding the old folder?

run_parsim_only
Unable to load bundle binary /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/bin/glnxa64/builtins/shared_dastudio_builtins/mwdastudio_builtinimpl.so. Error:
/lib64/libk5crypto.so.3: symbol EVP_KDF_ctrl version OPENSSL_1_1_1b not defined in file libcrypto.so.1.1 with link time reference: Success

Update: I tried all four versions of rehash, and the same error persists:

rehash

rehash path

rehash toolbox

rehash toolboxcache

[Tong Zhao]

Update: the cluster admin gave me a suggestion, and I quote:

Have you already tried changing the LD_LIBRARY_PATH after the module load? So do:

module reset

module load matlab

export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH

I am not sure if this will break MATLAB if there are other libraries that need to be the MATLAB ones and not the system ones. If that happens, just copy the system version of this library to a directory in your path and then point LD_LIBRARY_PATH to add that location first.

I followed his suggestions, by adding the path /usr/lib64 to the existing LD_LIBRARY_PATH variable, in addition to what @Walter Roberson suggested (copy the folder containing the 'bad' dll/so file to another place, hand pick out the 'bad' file, and replace the reference in LD_LIBRARY_PATH to this new folder. But, with all that it still gave me the same error:

Unable to load bundle binary /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen/gcc-8.3.1/matlab-2020b-o5lrpkierrdeih7cfjaxm3yofipxbff6/bin/glnxa64/builtins/shared_dastudio_builtins/mwdastudio_builtinimpl.so. Error:
/usr/lib64/libk5crypto.so.3: symbol EVP_KDF_ctrl version OPENSSL_1_1_1b not defined in file libcrypto.so.1.1 with link time reference: Success

I'm thinking if there's a way to set priority of a file in environment variables, so that instead of getting shadowed, it always will be picked first? But apart from that, I'm still confused why matlab still produces the same error pointing to the file libcrypto.so.1.1, which was supposedly removed from LD_LIBRARY_PATH already.

[Walter Roberson]

I'm thinking if there's a way to set priority of a file in environment variables, so that instead of getting shadowed, it always will be picked first?

That is what the LD_LIBRARY_PATH does. The search order starts from the first directory in the environment variable. (Though at the moment I do not recall if Linux also permits a search path to be compiled into executables. I seem to recall that it does. Such a compiled-in path is necessary to proper security functioning of suid / sguid executables, which must ignore LD_LIBRARY_PATH since the user is permitted to change LD_LIBRARY_PATH .)