Opera 3D R18.2 is a FEA software compiled for RHEL 7. In Leap 42.3 I could start the software by creating symlinks to various libraries that in RHEL have different names. The program complained in this fashion:
opera_manager: /lib64/libcrypto.so.10: no version information available (required by opera_manager)
and so on but started and worked as expected despite the command line output. In Leap 15.0 the command line output is different as specific versions of the libraries are required:
opera_manager: /usr/lib64/libcrypto.so.10: version `libcrypto.so.10' not found (required by opera_manager)
opera_manager: /usr/lib64/libcrypto.so.10: version `libcrypto.so.10' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
opera_manager: /usr/lib64/libcrypto.so.10: version `OPENSSL_1.0.1_EC' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
opera_manager: /usr/lib64/libcrypto.so.10: version `OPENSSL_1.0.1' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
opera_manager: /usr/lib64/libssl.so.10: version `libssl.so.10' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
/usr/lib64/libcrypto.so.10 is a symlink to /usr/lib64/libcrypto.so.1.0.0
/usr/lib64/libssl.so.10 is a symlink to /usr/lib64/libssl.so.1.0.0
and this output is more severe as the software now refuses to run. Any easy way to get around the version requirement?
Easy? Well hopefully won’t introduce any security issue…?
Anyway, why not look at using the system libraries to see if they work instead?
In your output it’s linking to the application libs eg libQt5Network.so.5 this is should be present as a system library, so if you just move/rename the application one, the binary should look for the system version rather than the application one…
Using the command ldd <somebinary> will show where it’s looking, there may even be a command line option to use system libs rather than application ones…?
It will be kind of tricky to do what you suggest which I guess is to replace the application library libQt5Network.so.5 with the system one. Correct me if I misunderstood. The software resides on another computer and the directory is accessed via nfs. So I would have to copy my /usr/lib64/libQt5Network.so.5 or rather what it points to to the other machine and redirect the symlinks there if they are different. If it works it will be a better solution for me and it’s only one library so it’s worth a try, I guess. The application libQt5Network.so.5 is a symlink pointing to libQt5Network.so.5.6.0 and the system library is /usr/lib64/libQt5Network.so.5.9.4 which is newer and should be compatible unless there are other version requirements. I’ll have a go. Not very many except me is using the software anyway so it’s not likely that anybody will notice.
Tried replacing the application library libQt5Network.so.5.6.0 with system library libQt5Network.so.5.9.4 and replaced the symlinks but my fears were grounded and I got this:
opera_manager: /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Core.so.5: version `Qt_5.9' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
opera_manager: /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Core.so.5: version `Qt_5.9.4_PRIVATE_API' not found (required by /net/wave1/opt/local/opera3d/18.2/code/bin/../lib/libQt5Network.so.5)
So, I will revert my changes on the other machine and try to get someone to examine the libraries I found to see if there are any threats before I put them to use again.
I have now restored my system to a pristine out-of-the-box state regarding this particular application
I tried now hiding the appliction libQt5Network.so.5.6.0 and the link to it by moving them to another directory outside of /net/wave1/opt/local/opera3d/18.2/code/lib but that did not have any effect. Apparently the application does not allow using the system Qt 5 stack. All I get is the following:
opera_manager: error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory
no matter if the application libQt5Network.so.5.6.0 is there or not. Should I try to hide the entire application Qt 5 stack? There are quite a few files in there:
and it seems like the application uses it’s own library to a fairly large extent, mostly Qt 5 but there are also others. I had satisfied the need for libpng15.so.15 by installing a community package but that just got chucked out because I tested a fix that Jonathan Brielmaier did for the broken menu in Mate bug 1144346
Looks like you will be stuck then I would suggest just popping the lib in with the other application libs and then just keep an eye on the package if it updates and you then need to replace the lib with the later one.
Do you mean that I should put the potentially dangerous libs I found in the lib-directory of the application? That could work and it would mean that there would hardly be any risk of compromising my own system, particularly since the application is loaded as an Environment Module and therefore always lives in a separate process tree. Since the machine only is a file server via nfs it means that no part of the application runs on it so I can’t imagine that the libs could possibly do any harm there. Anyway, since I administer this part of the other machine mysefl I’ll now when I need to do something about the libs. Perhaps a working solution.
Too bad, isn’t it. My work requires me to be able to run this application and it’s starting to look like I’ll have to leave OpenSuse after having used it for nearly 10 years :(. Our computer support team favours Ubuntu and CentOS. With OpenSuse I am on my own as the OpenSuse man has retired. CentOS 7 is about as close as you can get to RHEL 7 without actually being there so there’s a good chance CentOS will work. Even if tweaking the app library and continue with Leap works in this case there will be issues popping up now and then and I must admit that there is a great deal of comfort in being able to just pick up the phone or send a mail when things need to be sorted out.
Well it’s not dangerous, just if there is a security fix or CVE raised, just need to be across the package you extracted it from to ensure it gets updated if needed…
Either in the directory, or if you put them in /usr/local/lib the application should find them as it’s in the ldconf search path, just make sure you run the command ldconfig to ensure the cache is updated.