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
Show older comments
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
R = matlabroot()
findstr(strcat(path(),':'),strcat(R,':'))
I don't see any reason why it should be on the Search Path.
Tong Zhao
on 16 Feb 2022
Stephen23
on 16 Feb 2022
@Tong Zhao: please show the output of this command:
findstr(strcat(path(),':'),strcat(R,':'))
Accepted Answer
More Answers (1)
Walter Roberson
on 16 Feb 2022
1 vote
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
on 16 Feb 2022
Walter Roberson
on 16 Feb 2022
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
Walter Roberson
on 16 Feb 2022
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()
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 .)
Categories
Find more on Startup and Shutdown in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
