| Summary: | emacs requires libotf.so.0 which can be spoofed by openmpi; Emacs should require libotf explicitly | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Bob Arendt <rda> |
| Component: | openmpi | Assignee: | Jay Fenlason <fenlason> |
| Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | CC: | btotty, jfeeney, jhunt, rgm+rh, stephan.wiesand |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-31 14:39:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 782183 | ||
|
Description
Bob Arendt
2012-03-22 17:42:49 UTC
The Fedora 16 openmpi.spec file looks like it takes care of this. Example: RHEL 6.2: % rpm -q --provides openmpi |grep lib libmca_common_sm.so.2 libmpi.so.1 libmpi_cxx.so.1 libmpi_f77.so.1 libmpi_f90.so.1 libompi_dbg_msgq.so libompitrace.so.0 libopen-pal.so.2 libopen-rte.so.2 libotf.so.0 libvt-hyb.so.0 libvt-mpi.so.0 libvt-mt.so.0 libvt.so.0 mca_maffinity_libnuma.so Fedora 16: % rpm -q --provides openmpi |grep lib libmpi.so.1()(64bit) libmpi_cxx.so.1()(64bit) libmpi_f77.so.1()(64bit) libmpi_f90.so.1()(64bit) This was addressed for Fedora 15 & 16 by Bug 741104 I think the situation is actually worse than this. OpenMPI's libotf lives in /usr/lib64/openmpi/lib, so by default it is not visible to other applications. If you want to use OpenMPI, you are supposed to use: module load openmpi-x86_64 to make it available. Part of what this does is to add /usr/lib64/openmpi/lib to the front of LD_LIBRARY_PATH. If you then run emacs -Q and type C-h h to view the HELLO file (or try to open any other file that contains complex characters), Emacs crashes with: /usr/bin/emacs: symbol lookup error: /usr/bin/emacs: undefined symbol: OTF_open because it finds the wrong libotf.so thanks to LD_LIBRARY_PATH. So basically it is impossible to actually _use_ both Emacs and OpenMPI on RHEL6. I suppose a workaround might be to build the emacs rpm using LDFLAGS=-Wl,-rpath=/usr/lib64, so that it prefers the libraries from /usr/lib64 to any in LD_LIBRARY_PATH. Not really. The real problem is that the libotf package isn't pulled in during install, since yum/rpm believes the libotf.so requirement is satisfied by openmpi. If libotf is installed, no problem. Sorry, comment 4 was intended as a possible solution to the crash issue in comment 3; not the installation issue in comment 1, which is solved in comment 2. Open MPI package should not claim to provide libotf.so.0, as it is a private library. The corresponding Provides filter has been already tested in Fedora. The workaround of depending on libotf directly does not solve the issue for other (possibly 3rd party) packages. I agree Karel, this is more appropriately an openmpi issue. Thank you for re-assigning the bug. I noticed Red Hat just asserted the NEEDINFO flag on this bug, but I don't seen associated questions or unanswered questions. What INFO do you NEED? This is fixed in 6.3 *** This bug has been marked as a duplicate of bug 768457 *** |