RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 806031 - emacs requires libotf.so.0 which can be spoofed by openmpi; Emacs should require libotf explicitly
Summary: emacs requires libotf.so.0 which can be spoofed by openmpi; Emacs should requ...
Keywords:
Status: CLOSED DUPLICATE of bug 768457
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openmpi
Version: 6.2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jay Fenlason
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 782183
TreeView+ depends on / blocked
 
Reported: 2012-03-22 17:42 UTC by Bob Arendt
Modified: 2014-08-31 23:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-31 14:39:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Bob Arendt 2012-03-22 17:42:49 UTC 
Description of problem:

Emacs has a dependency on libotf.so.0.  openmpi claims to provide libotf.so.0, so kickstart and yum will happily install both and *not* require libotf.  When emacs starts up, it fails complaining that it cannot load libotf.so.  Which makes sense, since openmpi installs it's library for private use in /usr/lib/openmpi/lib/libotf.so.0.  I don't even know of openmpi's libotf is equivalent of libotf or if it's a library naming collision.


Version-Release number of selected component (if applicable):
emacs-23.1-21.el6_2.3.i686
openmpi-1.5.3-3.el6.i686

How reproducible:
Always


Steps to Reproduce:
1. Do not install libotf
2. Install openmpi
3. install emacs
4. start emacs from the command line;  It fails due to a a missing libotf.so.0 library.
  
Actual results:
emacs fails at the command line.  Installation of emacs should explicitly require "libotf" rather than just libotf.so.0.

Expected results:
emacs should just run.  Kickstart should pull in the correct dependencies.  Right now it's pulling openmpi instead of libotf.

Additional info:
The emacs.spec should have an explicit
Requires: libotf
.. statement to pull in the libotf rpm.

The *real* problem is thatthe openmpi package is bundling private libraries but advertising them as publicly available.  This is a side-effect of rpmbuild's automatic "Provides" scan listing anything that's a .so file as "provided", regardless of whether or not it's installed in the dynamic linker's default path.  So part of the blame could go to rpmbuild as well.

But the simplest work-around is to have emacs explicitly require libotf package itself.
Comment 2 Bob Arendt 2012-03-26 20:15:05 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
Comment 3 Glenn Morris 2012-05-09 00:27:00 UTC 
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.
Comment 4 Glenn Morris 2012-06-28 17:24:27 UTC 
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.
Comment 5 Bob Arendt 2012-06-28 19:45:32 UTC 
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.
Comment 6 Glenn Morris 2012-06-28 20:33:50 UTC 
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.
Comment 7 Karel Klíč 2012-07-17 08:10:38 UTC 
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.
Comment 8 Bob Arendt 2012-07-17 15:30:07 UTC 
I agree Karel, this is more appropriately an openmpi issue.  Thank you for re-assigning the bug.
Comment 10 Bob Arendt 2012-07-30 17:17:44 UTC 
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?
Comment 11 Stephan Wiesand 2012-07-31 11:11:39 UTC 
This is fixed in 6.3
Comment 12 Jay Fenlason 2012-07-31 14:39:28 UTC 

*** This bug has been marked as a duplicate of bug 768457 ***
Note You need to log in before you can comment on or make changes to this bug.