Bug 806031
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: | |
Embargoed: | |||
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 *** |