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:
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.
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.
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.
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.
Backport of rawhide openmpi to f15 resolves this.
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
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
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).
(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?
(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)?
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
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
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.
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.