FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-06-2011, 10:03 AM
Amit Saha
 
Default OpenMPI, Emacs and libotf problems

Hello all:

I am hoping it is OK to discuss this here. I came across this problem
when I was building a custom spin where the kickstart file installs
'openmpi' before 'emacs'.

When I start emacs, here is what I get:

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

So, this library is missing. However, this should have been installed
as its a dependency, right?

It can be seen that there are two providers listed for libotf.so.0.
Since 'openmpi' was already installed, so it didn't bother installing
'libotf'. I could simulate the scenario on a Fedora 15 installation:


Step1: Dependency listing
---------------------------------

$yum deplist emacs

dependency: libotf.so.0
provider: openmpi.i686 1.5-3.fc15
provider: libotf.i686 0.9.12-2.fc15



To verify this scenario, the next step attempts to install emacs on a
machine without emacs, libotf and openmpi:

Step 2: Installing emacs
------------------------------

[gene@soma ~]$ sudo yum install emacs
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package emacs.i686 1:23.2-19.fc15 will be installed
--> Processing Dependency: libotf.so.0 for package: 1:emacs-23.2-19.fc15.i686
--> Running transaction check
---> Package libotf.i686 0:0.9.12-2.fc15 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================== =========================================
Package Arch Version
Repository Size
================================================== =========================================
Installing:
emacs i686 1:23.2-19.fc15
updates 2.0 M
Installing for dependencies:
libotf i686 0.9.12-2.fc15
fedora 82 k

Transaction Summary
================================================== =========================================
Install 2 Package(s)

Total download size: 2.1 M


all good here.

(I don't proceed with the install)



Step 3: Installing openmpi
------------------------------
Next, I just install openmpi, which is listed as a provider for libotf.so.0:

[gene@soma ~]$ sudo yum install openmpi
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openmpi.i686 0:1.5-3.fc15 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================== =========================================
Package Arch Version
Repository Size
================================================== =========================================
Installing:
openmpi i686 1.5-3.fc15
fedora 1.7 M

Transaction Summary
================================================== =========================================
Install 1 Package(s)

Total download size: 1.7 M
Installed size: 6.7 M


Install done.

Step 4: Installing Emacs after installing openmpi
---------------------------------------------------------------

[gene@soma ~]$ sudo yum install emacs
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package emacs.i686 1:23.2-19.fc15 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================== =========================================
Package Arch Version
Repository Size
================================================== =========================================
Installing:
emacs i686 1:23.2-19.fc15
updates 2.0 M

Transaction Summary
================================================== =========================================
Install 1 Package(s)

Total download size: 2.0 M
Installed size: 6.5 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 2.0 M
emacs-23.2-19.fc15.i686.rpm |
2.0 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : 1:emacs-23.2-19.fc15.i686
1/1

Installed:
emacs.i686 1:23.2-19.fc15


It doesn;t list the dependeny anymore on libotf.so.0, since openmpi is
already installed.

And the result:

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


I also noted this discrepancy:

$sudo yum whatprovides libotf.so.0

Loaded plugins: langpacks, presto, refresh-packagekit
openmpi-1.5-3.fc15.i686 : Open Message Passing Interface
Repo : fedora
Matched from:
Other : libotf.so.0



libotf-0.9.12-2.fc15.i686 : A Library for handling OpenType Font
Repo : fedora
Matched from:
Other : libotf.so.0



openmpi-1.5-3.fc15.i686 : Open Message Passing Interface
Repo : installed
Matched from:
Other : Provides-match: libotf.so.0




$sudo yum whatprovides libotf
Loaded plugins: langpacks, presto, refresh-packagekit
libotf-0.9.12-2.fc15.i686 : A Library for handling OpenType Font
Repo : fedora
Matched from:


Found some older bugs [1], [2], possibly related.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=527657
[2] https://bugzilla.redhat.com/show_bug.cgi?id=496131


Sorry for the long email, and I would be very happy to give any more
feedback or answer any further questions or file a bug.

-Amit

--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 07:39 PM
Adam Williamson
 
Default OpenMPI, Emacs and libotf problems

On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> Hello all:
>
> I am hoping it is OK to discuss this here. I came across this problem
> when I was building a custom spin where the kickstart file installs
> 'openmpi' before 'emacs'.
>
> When I start emacs, here is what I get:
>
> $emacs
> emacs: error while loading shared libraries: libotf.so.0: cannot open
> shared object file: No such file or directory
>
> So, this library is missing. However, this should have been installed
> as its a dependency, right?
>
> It can be seen that there are two providers listed for libotf.so.0.
> Since 'openmpi' was already installed, so it didn't bother installing
> 'libotf'. I could simulate the scenario on a Fedora 15 installation:

The problem is that openmpi includes a libotf.so.0, but it's not in a
path that the system will usually look in for shared libraries, it's in
(libdir)/openmpi/lib/ . openmpi probably shouldn't have a private copy
of libotf in the first place (assuming that's what it is, and not just a
naming coincidence), but if it's going to have one, it should have a
line in the spec to prevent RPM auto-provides from giving the openmpi
package a Provides for libotf.so.0.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 07:46 PM
Jussi Lehtola
 
Default OpenMPI, Emacs and libotf problems

On Wed, 06 Jul 2011 12:39:14 -0700
Adam Williamson <awilliam@redhat.com> wrote:
> On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> > So, this library is missing. However, this should have been
> > installed as its a dependency, right?
> >
> > It can be seen that there are two providers listed for libotf.so.0.
> > Since 'openmpi' was already installed, so it didn't bother
> > installing 'libotf'. I could simulate the scenario on a Fedora 15
> > installation:
>
> The problem is that openmpi includes a libotf.so.0, but it's not in a
> path that the system will usually look in for shared libraries, it's
> in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
> copy of libotf in the first place (assuming that's what it is, and
> not just a naming coincidence), but if it's going to have one, it
> should have a line in the spec to prevent RPM auto-provides from
> giving the openmpi package a Provides for libotf.so.0.

It's certainly not the same libotf, since OpenMPI does not have
*anything* to do with truetype fonts.

Even though the library is installed in a non-system directory,
applications that link against libotf will get an automatically
generated Requires: against it anyways.

Maybe OpenMPI upstream should be contacted and asked to rename their
libotf.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 07:54 PM
Adam Williamson
 
Default OpenMPI, Emacs and libotf problems

On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote:
> On Wed, 06 Jul 2011 12:39:14 -0700
> Adam Williamson <awilliam@redhat.com> wrote:
> > On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> > > So, this library is missing. However, this should have been
> > > installed as its a dependency, right?
> > >
> > > It can be seen that there are two providers listed for libotf.so.0.
> > > Since 'openmpi' was already installed, so it didn't bother
> > > installing 'libotf'. I could simulate the scenario on a Fedora 15
> > > installation:
> >
> > The problem is that openmpi includes a libotf.so.0, but it's not in a
> > path that the system will usually look in for shared libraries, it's
> > in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
> > copy of libotf in the first place (assuming that's what it is, and
> > not just a naming coincidence), but if it's going to have one, it
> > should have a line in the spec to prevent RPM auto-provides from
> > giving the openmpi package a Provides for libotf.so.0.
>
> It's certainly not the same libotf, since OpenMPI does not have
> *anything* to do with truetype fonts.
>
> Even though the library is installed in a non-system directory,
> applications that link against libotf will get an automatically
> generated Requires: against it anyways.

Well, packages get an auto-generated Requires: for libotf.so.0. Anything
that claims to provide libotf.so.0 will satisfy this. The most correct
solution is simply for openmpi to stop claiming to provide libotf.so.0
because, for practical purposes, it does not provide it: even if the
library in question were the same one, openmpi's copy is not in a
location that other packages will know how to use, so in practical
terms, it does not provide the library.

> Maybe OpenMPI upstream should be contacted and asked to rename their
> libotf.

This would also indeed make sense. Googling 'openmpi libotf' I see that
at least Gentoo and Debian have come across this before.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:02 PM
Jussi Lehtola
 
Default OpenMPI, Emacs and libotf problems

On Wed, 06 Jul 2011 12:54:48 -0700
Adam Williamson <awilliam@redhat.com> wrote:
> > It's certainly not the same libotf, since OpenMPI does not have
> > *anything* to do with truetype fonts.
> >
> > Even though the library is installed in a non-system directory,
> > applications that link against libotf will get an automatically
> > generated Requires: against it anyways.
>
> Well, packages get an auto-generated Requires: for libotf.so.0.
> Anything that claims to provide libotf.so.0 will satisfy this. The
> most correct solution is simply for openmpi to stop claiming to
> provide libotf.so.0 because, for practical purposes, it does not
> provide it: even if the library in question were the same one,
> openmpi's copy is not in a location that other packages will know how
> to use, so in practical terms, it does not provide the library.

.. but on the other hand, the same logic applies in the opposite sense:
if something requires OpenMPI's libotf.so.0, also the truetype libotf
will satisfy the requirement. (Although openmpi apps typically link to
a half a dozen other openmpi libs as well).
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:09 PM
Adam Williamson
 
Default OpenMPI, Emacs and libotf problems

On Wed, 2011-07-06 at 23:02 +0300, Jussi Lehtola wrote:
> On Wed, 06 Jul 2011 12:54:48 -0700
> Adam Williamson <awilliam@redhat.com> wrote:
> > > It's certainly not the same libotf, since OpenMPI does not have
> > > *anything* to do with truetype fonts.
> > >
> > > Even though the library is installed in a non-system directory,
> > > applications that link against libotf will get an automatically
> > > generated Requires: against it anyways.
> >
> > Well, packages get an auto-generated Requires: for libotf.so.0.
> > Anything that claims to provide libotf.so.0 will satisfy this. The
> > most correct solution is simply for openmpi to stop claiming to
> > provide libotf.so.0 because, for practical purposes, it does not
> > provide it: even if the library in question were the same one,
> > openmpi's copy is not in a location that other packages will know how
> > to use, so in practical terms, it does not provide the library.
>
> .. but on the other hand, the same logic applies in the opposite sense:
> if something requires OpenMPI's libotf.so.0, also the truetype libotf
> will satisfy the requirement. (Although openmpi apps typically link to
> a half a dozen other openmpi libs as well).

Nothing really could require OpenMPI's libotf as things stand, because
of what I wrote above: nothing can find it unless it uses a custom
linker path. If OpenMPI actually wanted the library to be something
other packages can use, it should really install it in a shared path
(and, as we've already discussed, rename it). If we're just talking
about different OpenMPI packages, they can handle the intra-dependencies
manually, I'd say.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:24 PM
Mátyás Selmeci
 
Default OpenMPI, Emacs and libotf problems

Adam Williamson wrote on Wed, Jul 06, 2011 at 12:54:48PM -0700:
> On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote:
> > On Wed, 06 Jul 2011 12:39:14 -0700
> > Adam Williamson <awilliam@redhat.com> wrote:
> > > On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote:
> > > > So, this library is missing. However, this should have been
> > > > installed as its a dependency, right?
> > > >
> > > > It can be seen that there are two providers listed for libotf.so.0.
> > > > Since 'openmpi' was already installed, so it didn't bother
> > > > installing 'libotf'. I could simulate the scenario on a Fedora 15
> > > > installation:
> > >
> > > The problem is that openmpi includes a libotf.so.0, but it's not in a
> > > path that the system will usually look in for shared libraries, it's
> > > in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private
> > > copy of libotf in the first place (assuming that's what it is, and
> > > not just a naming coincidence), but if it's going to have one, it
> > > should have a line in the spec to prevent RPM auto-provides from
> > > giving the openmpi package a Provides for libotf.so.0.
> >
> > It's certainly not the same libotf, since OpenMPI does not have
> > *anything* to do with truetype fonts.
> >
> > Even though the library is installed in a non-system directory,
> > applications that link against libotf will get an automatically
> > generated Requires: against it anyways.
>
> Well, packages get an auto-generated Requires: for libotf.so.0. Anything
> that claims to provide libotf.so.0 will satisfy this. The most correct
> solution is simply for openmpi to stop claiming to provide libotf.so.0
> because, for practical purposes, it does not provide it: even if the
> library in question were the same one, openmpi's copy is not in a
> location that other packages will know how to use, so in practical
> terms, it does not provide the library.

If I run into this kind of a situation (a false auto-generated
Provides), is it possible to disable just that one entry, or do I have
to disable AutoProv entirely and keep track of the libs myself?

Thanks,
-matyas

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:26 PM
Adam Williamson
 
Default OpenMPI, Emacs and libotf problems

On Wed, 2011-07-06 at 15:24 -0500, Mátyás Selmeci wrote:

> > Well, packages get an auto-generated Requires: for libotf.so.0. Anything
> > that claims to provide libotf.so.0 will satisfy this. The most correct
> > solution is simply for openmpi to stop claiming to provide libotf.so.0
> > because, for practical purposes, it does not provide it: even if the
> > library in question were the same one, openmpi's copy is not in a
> > location that other packages will know how to use, so in practical
> > terms, it does not provide the library.
>
> If I run into this kind of a situation (a false auto-generated
> Provides), is it possible to disable just that one entry, or do I have
> to disable AutoProv entirely and keep track of the libs myself?

http://fedoraproject.org/wiki/AutoReqProv_%28draft%
29#Removing_items_from_the_provides_stream_.28post-scan_filtering.29
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:33 PM
Jerry James
 
Default OpenMPI, Emacs and libotf problems

On Wed, Jul 6, 2011 at 2:26 PM, Adam Williamson <awilliam@redhat.com> wrote:
> http://fedoraproject.org/wiki/AutoReqProv_%28draft%29#Removing_items_from_the_pr ovides_stream_.28post-scan_filtering.29

Or rather https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering,
and I can't use that in a couple of similar cases due to the
restrictions in the Usage section.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-06-2011, 08:39 PM
Jussi Lehtola
 
Default OpenMPI, Emacs and libotf problems

On Wed, 06 Jul 2011 13:09:41 -0700
Adam Williamson <awilliam@redhat.com> wrote:
> > .. but on the other hand, the same logic applies in the opposite
> > sense: if something requires OpenMPI's libotf.so.0, also the
> > truetype libotf will satisfy the requirement. (Although openmpi
> > apps typically link to a half a dozen other openmpi libs as well).
>
> Nothing really could require OpenMPI's libotf as things stand, because
> of what I wrote above: nothing can find it unless it uses a custom
> linker path. If OpenMPI actually wanted the library to be something
> other packages can use, it should really install it in a shared path
> (and, as we've already discussed, rename it). If we're just talking
> about different OpenMPI packages, they can handle the
> intra-dependencies manually, I'd say.

Not really, since when the MPI environment is loaded the relevant
library paths are added to LD_LIBRARY_PATH.

They're not installed in system locations, since e.g. all MPI libraries
ship with libmpi.so, and there are many variants: OpenMPI, MPICH2,
MVAPICH, and so on.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org