Libcrypto.so.2 error, and Profile setup for a Linux HPC - RH8

[ryegreen]

After the installation, the program call yields an error: bin/python3: error while loading shared libraries: libcrypt.so.2: cannot open shared object file: No such file or directory.
Commands used in linux include: visit, visit &, visit -cli

Also, attempted to setup a profile to run visit using the Linux HPC installation: no go

How do I get around the library error?

[biagas]

libcrypt is part of openssl, you may need to install openssl on the RH8 system.

Did you install from one of our prebuilt-tarball on your the RH8 machine? If so, which tarball did you use?

Based on the icon from your snapshot, you are running VisIt locally on a Windows system attempting to connect to the remote RH8, correct? Did you create a host-profile for that system? Instructions for how to create a host profile can be found in our Host profiles docs.

[ryegreen]

Fedora had the same error regarding libcrypto.

This is what came up in the file search:
/intel/parallel_studio_xe_2020.3.11/uninstall/32e/libcrypto.so.1.0.0
/nvidia/host/linux-desktop-glibc_2_11_3-x64/libcrypto.so.1.1
/Pegasus/libcrypto.so.4

[biagas]

Been looking at my Rocky8 container where I did the build for 3.4.2 distribution. It doesn't have libcrypt.so.2. Nor can I find one of VisIt's components that depend on it, I only see libcrypt.so.1 when I look at dependencies using ldd. So now I am confused by the error related to the .so.2 version of the library.

In my google search I found one issue mentioning a problem related to python3.10 and libcrypt.so.2 not being available on the RH8 system. But VisIt is using python 3.9. I wonder if you have python3.10 installed on the system and it is being used instead of the 3.9 version provided by VisIt.

Can you try starting Visit again on the RH8 system? (just /path/to/visit/bin/visit, do not add -cli). Is the error message still related to libcrypt.so.2?
Or is it libcrypt.so.1?

In my Rocky8 container I did:
dnf provides *libcrypt.so.1

The results point to these packages as providing the library: libxcrypt-4.1.1-6.el8.x86_64 libxcrypt-4.1.1-6.el8.i686

[ryegreen]

Openssl is installed. The problem seems to be where the visit software is pointing/looking to find this library file. The file exists in the /usr/lib64/ directory. What is the best option to add a path or link the library file to another location?

Python 3.11 has been installed at the root, but Python 3.6 comes up at my user level.

The error is related to libcrypt.so.2

Is there a way to wipe all of the previous installations and start from scratch? (is there a possibility that we have left over script from previous installations of visit?)

[biagas]

I was incorrect in my first statement that libcrypt.so is part of openssl, it is not. Openssl has a similarly named library libcrytpo.so.
You can uninstall VisIt by simply deleting it from its install location. So if you run /usr/local/visit/bin/visit to launch VisIt, then delete /usr/local/visit. Unless there are multiple versions installed, then you would only want to uninstall the version causing problems, eg /usr/local/visit/3.4.2, after which you would need to update /usr/local/visit/current to point to a remaining version of VisIt.

As I mentioned previously, I don't know where the dependence on libcrypt.so.2 is coming from. You could duplicate my efforts of using ldd:

cd to the directory where 3.4.2 is installed, so something like /usr/local/visit/3.4.2/linux-x86_64/bin. If you don't use full path in your invocation of visit then do which visit to know for sure where its located.
Once in the bin directory, use 'ldd' command on a few of the executables like so:

ldd python3.9 | grep libcrypt.so

For me this yields:

    libcrypt.so.1 => /lib64/libcrypt.so.1 

Try a few more, report which (if any) report back with libcrypt.so.2.

ldd cli | grep libcrypt.so
ldd engine_ser | grep libcrypt.so
ldd viewer | grep libcrypt.so

[biagas]

I was reminded by another developer that you can run VisIt with strace in order to track down library loading issues.
Running:
visit -cli -strace --output strace_output.txt cli
will run strace on the cli component, and put its output into strace_output.txt. You could then search the file for the libcrypt.so.2 entries, or python related entries. It might show that visit is trying to load a different version of python than what is expected. If you want help parsing the output, you can tar it up and post it here. Just be aware that the file will contain a lot of system information so if that is sensitive don't post.

[ryegreen]

[ryegreen]