New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add missing system libraries to rhel7 distributions. #5932
Comments
I believe I should actually use the libstdc++.so.6 from the latest gcc I can find, possibly from Fedora34. This will work with all older compilers and work on the most systems. This because it will have the most versions of the GLIBCXX_3.4.* symbol. libstdc++.so.6.0.29 from Fedora34 goes all the way up to GLIBCXX_3.4.29. This is documented in #5664. |
Hi, will there be a rhel7 version of 3.2.2? |
Yes, it isn't ready quite yet. |
The rhel7 version is now available. |
Thanks! This time I did not see any need for libstdc++ and this is not in the distribution. Perhaps a dynamical link? I did have to put in the libicuin18n.so.50 stuff. I got these dangling link errors: chmod: cannot operate on dangling symlink '/usr/local/visit/3.2.2+/linux-x86_64/bin/python3-config' By the way, visit is still not working via ssh -X connection on Fedora 35. If I start visit on the remote system (FC35 too) the Thanks!4 |
I downloaded the rhel7 version. The window on the right is frozen (Window 1). Even the release notes window was frozen. The one on the left keeps operating fine, I can Open files etc. I can also exit properly. |
The rhel7 version was built against the system OpenGL libraries and in my experience when forwarding over X, "Window 1" is unresponsive. For example, sshing from a VNC window to my RHEL7 system and running VisIt displaying back to the VNC system. I don't know what the issue is. For that case the rhel7-wmesa usually works. |
The rhel7 version is compiled with gcc9.1, which isn't natively available on rhel7. Because of this it won't run on a generic rhel7 system, in fact, if the gcc9.1 lib directory isn't in the LD_LIBRARY_PATH, it won't even run on the system it was built. We should add the libstdc++.so.6 that goes with gcc9.1 to the binary distribution in the lib directory.
We should also add the libicu*.so.50 libraries, since those are dependencies for Qt and those aren't in later OSes. They come from libQt5Core.so.5. Doing an ldd on libQtCore.so.5 shows that the following libicu*.so.50 libraries should be added (This is from an e-mail, it should be double checked).
/lib64/libicuin18n.so.50
/lib64/libicudata.so.50
/lib64/libicuuc.so.50
The text was updated successfully, but these errors were encountered: