Bug 126824 - libaio.so not created when libaio installed
libaio.so not created when libaio installed
Product: Fedora
Classification: Fedora
Component: lam (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Depends On:
  Show dependency treegraph
Reported: 2004-06-27 21:41 EDT by Samit Basu
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: lam-7.1.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-02 18:24:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Samit Basu 2004-06-27 21:41:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET 
CLR 1.1.4322)

Description of problem:
A symlink of "libaio.so" is not created when libaio is installed.  
This happens to break the lam package.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.install libaio

Additional info:
Comment 1 Jeffrey Moyer 2004-11-01 17:41:06 EST
I don't believe lam requires this symlink to be there.  Please verify this.  I
will, however, update the package to create the symlink, since it should be there.

Comment 2 Jeffrey Moyer 2004-11-01 17:44:14 EST
Sorry, the .so file is there, it's in the -devel package.  This is where it
belongs.  If you are not having problems installing lam, I'd like to close this bug.
Comment 3 Samit Basu 2004-11-01 21:30:08 EST
To clarify a little - installing the lam rpm requires libaio to be 
installed as a prerequisite (not the -devel package, as far as I can 
tell).  Although the lam package appears to install OK, it is, in 
fact broken, as attempting to run the MPI compiler demonstrates:

[basu@siren basu]$ mpicc hello.c
/usr/bin/ld: cannot find -laio
collect2: ld returned 1 exit status
mpicc: No such file or directory
[basu@siren basu]$

Adding the .so reference by hand appears to fix the problem.
Comment 4 Samit Basu 2004-11-01 21:34:01 EST
Also - this is probably a novice question on my part - but what is 
the point of installing (or providing) a libaio package that installs 
a libaio.so.1 and a libaio.so.1.0.0 but no libaio.so?  Why would the 
dynamic library only belong in the -devel form of the package?
Comment 5 Michael Schwendt 2004-11-02 05:36:12 EST
It belongs into the -devel package only, because it is a version-less
shared object, which is required at compile/link-time (here, too!) and
must not be required at run-time. Occasionally, there are
applications, which access such library file names at run-time, but
they ought to be fixed to access the versioned libraries instead. If
the libaio.so soft-link were included in the main libaio package, it
would be more difficult to install multiple versions of libaio at
once, because only one libaio.so could be in default linker search path.

The issue here is that "lam" is a development/programming system and
hence may depend on -devel packages to be installed in order to work
fully. Here the MPI compiler asks the linker to link against libaio.
Not requiring libaio-devel would be like a C++ compiler without C++
Standard library and headers.
Comment 6 Michael Schwendt 2004-11-02 05:42:58 EST
Btw, mpic++ wants gcc-c++, mpif77 wants gcc-g77, mpicc wants gcc
Comment 7 Lon Hohberger 2004-11-03 09:13:27 EST
I've built a new lam package with the proper requires line for the
compilers and libaio-devel.  However, it will be a while before it
appears in rawhide due to the fact the we are past the Fedora Core 3
development freeze.
Comment 8 Satish Balay 2005-01-31 12:19:40 EST
How about FC3 updates?
Comment 9 Satish Balay 2005-01-31 13:51:07 EST
BTW: I don't see the update in rawhide or cvs yet..


BuildRequires: gcc-g77 fileutils perl gcc
Requires: openssh-server openssh-clients
Comment 11 Satish Balay 2005-01-31 14:37:53 EST
I don't see the new dependency on 'aio-devel' (or libaio.so or g++)

#rpm -qp --requires lam-7.0.6-3.i386.rpm 
config(lam) = 2:7.0.6-3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

# yum install lam
Dependencies Resolved
Transaction Listing:
  Install: lam.i386 2:7.0.6-3 - base

Performing the following to resolve dependencies:
  Install: libaio.i386 0:0.3.102-1 - base
Total download size: 2.3 M
Is this ok [y/N]: 
Comment 12 Jason Vas Dias 2005-01-31 14:51:00 EST
Yes, but as noted in the previous comments, lam should be depending
on a versioned libaio.so, and now does correctly depend on 
libaio.so.1.0.0, which was picked up by yum update which prompted 
you to install libaio .
Comment 13 Satish Balay 2005-01-31 15:29:37 EST
From what I understand from this bugzilla - lam is unuseable unless
libaio-devel is installed (and a bunch of compilers also installed)

Ref: comment 3 & comment 6

Whatever you've done hasn't solved this problem.

Its not like fedora has lam & lam-devel  (and the devel version has
the correct devel dependencies).
Comment 14 Satish Balay 2005-01-31 15:44:25 EST
BTW: lam should also have:

BuildRequires: gcc-c++, libaio-devel

[apart from the primary requirement]

Requires: gcc-g77, gcc-c++, libaio-devel

Comment 15 Jason Vas Dias 2005-02-02 18:24:47 EST
lam is now upgraded to version 7.1.1-1 in FC4 and will shortly be
in fc3-updates / fc2-updates - meanwhile, you can download it from:
It also definitely fixes the libaio{,-devel} dependency problem.
Comment 16 Satish Balay 2005-02-04 10:34:01 EST
7.1.1-1 in rawhide appears to work as expected. 


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