Bug 741104 - emacs doesn't work after install through yum (x86_64)
emacs doesn't work after install through yum (x86_64)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openmpi (Show other bugs)
15
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-25 07:32 EDT by Gerard Ryan
Modified: 2013-02-21 05:23 EST (History)
8 users (show)

See Also:
Fixed In Version: openmpi-1.5.4-3.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-01 14:28:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gerard Ryan 2011-09-25 07:32:06 EDT
Description of problem:
I did a 'yum install emacs', and it appeared to install successfully. Then when I tried to run it ('emacs' in terminal), I get the following error:

emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory

I realise I could just 'yum install libotf.so.0' - but I expect that if it's needed, yum should pull it in on emacs install.


Version-Release number of selected component (if applicable):
emacs-23.2-19.fc15.x86_64

How reproducible:
100%

Steps to Reproduce:
1. sudo yum install emacs
2. attempt to run emacs in a terminal
3. (this is where the error is produced
  
Actual results:
emacs should run successfully, without any errors

Expected results:
emacs doesn't run, throws an error

Additional info:
Comment 1 Karel Klíč 2011-09-27 04:58:43 EDT
Installing libotf should solve the problem for you.

Every package requiring libotf.so.0 is affected by this problem.

This was discussed on fedora-devel mailing list:
http://lists.fedoraproject.org/pipermail/devel/2011-July/153841.html

The most correct solution is for Open MPI RPM to stop providing libotf.so.0.
Open MPI upstream could be asked to rename the library.
Comment 2 Doug Ledford 2011-09-29 09:18:45 EDT
libotf in openmpi has nothing to do with font management, unlike the upstream libotf.  I can see if openmpi wants to rename it, but as it's an internal library, and I'm pretty sure it's dlopen()ed as opposed to hard linked, just getting rpm to stop picking it up in the rpm provides would be sufficient too.  If anyone knows how to stop rpmbuild from picking up those provides, that would be helpful.
Comment 3 Orion Poplawski 2011-11-16 19:15:15 EST
https://fedoraproject.org/wiki/User:Tibbs/AutoProvidesAndRequiresFiltering

# Private openmpi libraries
%define __provides_exclude_from %{_libdir}/openmpi/lib/(lib(mca|o|v)|openmpi/).*.so
%define __requires_exclude lib(mca|o|v).*

I'm ready to queue this up along with 1.5.4 to rawhide.  Could be added to F15/F16 in updates.
Comment 4 Yann Droneaud 2011-12-05 12:04:44 EST
I'm having the same problem right now under Fedora 16: I installed emacs with yum install emacs, and now I'm getting those message
emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory

BTW, I wonder why I have openmpi libraries installed on my default Fedora 16 install.
Comment 5 Doug Ledford 2012-01-20 10:57:27 EST
Backport of rawhide openmpi to f15 resolves this.
Comment 6 Fedora Update System 2012-01-20 14:19:52 EST
openmpi-1.5.4-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/openmpi-1.5.4-3.fc16
Comment 7 Fedora Update System 2012-01-20 14:20:22 EST
openmpi-1.5.4-3.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/openmpi-1.5.4-3.fc15
Comment 8 Fedora Update System 2012-01-21 16:50:22 EST
Package openmpi-1.5.4-3.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openmpi-1.5.4-3.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0725/openmpi-1.5.4-3.fc15
then log in and leave karma (feedback).
Comment 9 Thomas Spura 2012-01-24 14:35:04 EST
(In reply to comment #2)
> libotf in openmpi has nothing to do with font management, unlike the upstream
> libotf.  I can see if openmpi wants to rename it, but as it's an internal
> library, and I'm pretty sure it's dlopen()ed as opposed to hard linked, just
> getting rpm to stop picking it up in the rpm provides would be sufficient too. 
> If anyone knows how to stop rpmbuild from picking up those provides, that would
> be helpful.

This is not good for rpm...

With not providing the own private libraries mpi4py will have a dependency issue, means I would be forced to turn it off there too (and add the openmpi dependency on my own)...
This is not the intent of the automatic provides of rpm ;)

A different solution would be to require the proper package with libodf inside so this is prefered, when installing emacs and mpi4py picks openmpi instead.

Doug, could you turn on the private libraries again please?
Comment 10 Doug Ledford 2012-01-24 15:10:11 EST
(In reply to comment #9)
> (In reply to comment #2)
> > libotf in openmpi has nothing to do with font management, unlike the upstream
> > libotf.  I can see if openmpi wants to rename it, but as it's an internal
> > library, and I'm pretty sure it's dlopen()ed as opposed to hard linked, just
> > getting rpm to stop picking it up in the rpm provides would be sufficient too. 
> > If anyone knows how to stop rpmbuild from picking up those provides, that would
> > be helpful.
> 
> This is not good for rpm...
> 
> With not providing the own private libraries mpi4py will have a dependency
> issue, means I would be forced to turn it off there too (and add the openmpi
> dependency on my own)...
> This is not the intent of the automatic provides of rpm ;)
> 
> A different solution would be to require the proper package with libodf inside
> so this is prefered, when installing emacs and mpi4py picks openmpi instead.
> 
> Doug, could you turn on the private libraries again please?

I need you to elaborate more.  Are you saying that mpi4py has an auto dependency on libotf, but it's on the openmpi libotf versus the font manager?  If so, why does mpi4py have a dependency on libotf from openmpi, but not on openmpi in general (libmpi)?
Comment 11 Thomas Spura 2012-01-24 15:46:59 EST
You can try this on F16 (or rawhide of course):
# yum install mpi4py-openmpi --enablerepo=updates-testing
Error: Package: mpi4py-openmpi-1.3-1.fc16.x86_64 (updates-testing)
           Requires: libvt-mpi.so.0()(64bit)
           Available: openmpi-1.5-4.fc16.x86_64 (fedora)
               libvt-mpi.so.0()(64bit)
           Installed: openmpi-1.5.4-3.fc16.x86_64 (@/openmpi-1.5.4-3.fc16.x86_64)
               Not found
Error: Package: mpi4py-openmpi-1.3-1.fc16.x86_64 (updates-testing)
           Requires: libvt-hyb.so.0()(64bit)
           Available: openmpi-1.5-4.fc16.x86_64 (fedora)
               libvt-hyb.so.0()(64bit)
           Installed: openmpi-1.5.4-3.fc16.x86_64 (@/openmpi-1.5.4-3.fc16.x86_64)
               Not found

mpi4py-openmpi has this dependencies (among others):
libmpi.so.1()(64bit)
libutil.so.1()(64bit)
libvt-hyb.so.0()(64bit)
libvt-mpi.so.0()(64bit)
mpi4py-common = 1.3-1.fc17
openmpi

mpi4py builds e.g. a own version of libvt.so, so it can preload the own definitions of libvt.so and trace all mpi calls and enabling profiling on runtime.

Here are the full dependency of the build libraries:

ldd ~/rpmbuild/BUILDROOT/mpi4py-1.3-1.fc16.x86_64/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/lib*.so
/home/tom/rpmbuild/BUILDROOT/mpi4py-1.3-1.fc16.x86_64/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/libmpe.so:
	linux-vdso.so.1 =>  (0x00007fff55580000)
	libmpi.so.1 => /usr/lib64/openmpi/lib/libmpi.so.1 (0x00007f01a65a6000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f01a637c000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f01a6160000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f01a5daa000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f01a5b8f000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f01a598c000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f01a5708000)
	libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f01a54fe000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c30c00000)
/home/tom/rpmbuild/BUILDROOT/mpi4py-1.3-1.fc16.x86_64/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/libvt-hyb.so:
	linux-vdso.so.1 =>  (0x00007fff41b36000)
	libvt-hyb.so.0 => /usr/lib64/openmpi/lib/libvt-hyb.so.0 (0x00007f13952ce000)
	libmpi.so.1 => /usr/lib64/openmpi/lib/libmpi.so.1 (0x00007f1394f5f000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1394d36000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1394b1a000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1394763000)
	libotf.so.0 => /usr/lib64/openmpi/lib/libotf.so.0 (0x00007f1394534000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f139431d000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f1394102000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f1393eff000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f1393c7b000)
	libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f1393a71000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c30c00000)
/home/tom/rpmbuild/BUILDROOT/mpi4py-1.3-1.fc16.x86_64/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/libvt-mpi.so:
	linux-vdso.so.1 =>  (0x00007fff1d5ff000)
	libvt-mpi.so.0 => /usr/lib64/openmpi/lib/libvt-mpi.so.0 (0x00007fc52e602000)
	libmpi.so.1 => /usr/lib64/openmpi/lib/libmpi.so.1 (0x00007fc52e293000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc52e06a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc52de4e000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc52da97000)
	libotf.so.0 => /usr/lib64/openmpi/lib/libotf.so.0 (0x00007fc52d868000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc52d651000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc52d436000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007fc52d233000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fc52cfaf000)
	libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007fc52cda5000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c30c00000)
/home/tom/rpmbuild/BUILDROOT/mpi4py-1.3-1.fc16.x86_64/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/libvt.so:
	linux-vdso.so.1 =>  (0x00007fff15bff000)
	libvt-mpi.so.0 => /usr/lib64/openmpi/lib/libvt-mpi.so.0 (0x00007f75f78a8000)
	libotf.so.0 => /usr/lib64/openmpi/lib/libotf.so.0 (0x00007f75f7678000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f75f743c000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f75f7238000)
	libmpi.so.1 => /usr/lib64/openmpi/lib/libmpi.so.1 (0x00007f75f6ec9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f75f6cad000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f75f68f7000)
	libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f75f66dc000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f75f64d9000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f75f6255000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c30c00000)
	libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f75f604b000)


So I could turn off the automatic dependency generator for those files and would be forced to add all dependencies manually (and checking if they change in a new release). But the easy way would be to let emacs require the proper libodf and let yum do the rest.
(Furthermore, I don't know if this change breaks other packages.)

If you prefer me to turn of the automatic dependencies for those files, let me know:
/usr/lib64/python2.7/site-packages/openmpi/mpi4py/lib-pmpi/*.so
Comment 12 Thomas Spura 2012-01-25 11:39:41 EST
I have talked with mpi4py upstream and I disabled the automatic requirement for the internal openmpi libraries now...

I still think, it would be best to do it like described above, because this could break other packages (at least in theory), but it's fine to do it like this, till there actually is a package, that is broken ;)

This should fix the daily broken deps nag mail:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3732109
Comment 13 Fedora Update System 2012-02-01 14:28:57 EST
openmpi-1.5.4-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Fedora Update System 2012-02-01 14:30:02 EST
openmpi-1.5.4-3.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.