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

70 views (last 30 days)
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?
  4 Comments
Tong Zhao
Tong Zhao on 16 Feb 2022
Edited: Tong Zhao on 16 Feb 2022
@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?

Sign in to comment.

Accepted Answer

Tong Zhao
Tong Zhao on 17 Feb 2022
Edited: Tong Zhao on 17 Feb 2022
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.

More Answers (1)

Walter Roberson
Walter Roberson on 16 Feb 2022
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.)
  7 Comments
Tong Zhao
Tong Zhao on 16 Feb 2022
Edited: Tong Zhao on 16 Feb 2022
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
Walter Roberson on 17 Feb 2022
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 .)

Sign in to comment.

Categories

Find more on Startup and Shutdown in Help Center and File Exchange

Products


Release

R2020b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!