Bug 154146 - libattr-devel provides .la file which creates dangling references to /lib/libattr.la
libattr-devel provides .la file which creates dangling references to /lib/lib...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: acl (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
:
Depends On:
Blocks: 171114
  Show dependency treegraph
 
Reported: 2005-04-07 15:08 EDT by Nalin Dahyabhai
Modified: 2009-03-15 17:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 06:50:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nalin Dahyabhai 2005-04-07 15:08:22 EDT
Description of problem:
libattr-devel provides /usr/lib/libattr.la which includes the statement
"libdir='/lib'", causing .la files which link against libattr.la (for example,
libacl.la) to record a dependency on /lib/libattr.la.

Version-Release number of selected component (if applicable):
libacl-devel-2.2.23-8

How reproducible:
Always

Steps to Reproduce:
1. Rebuild libacl against installed libattr and install the generated libacl-devel.
2. cat > foo.c << EOF
   int main(int argc, char **argv) { return 0; }
   EOF
3. libtool --mode=compile gcc -c -o foo.lo foo.c
4. libtool --mode=link    gcc -o foo foo.lo -lacl
  
Actual results:
libtool: link: cannot find the library `/lib/libattr.la'

Expected results:
No messages, successful link.

Additional info:
Packages containing the dangling link (which appears to just be libacl-devel)
will need to rebuilt after this is fixed.
Comment 1 Peter O'Gorman 2005-09-08 08:53:38 EDT
The fix is probably as simple as adding s symlink /lib/libattr.la -> /usr/lib/libattr.la, but I don't really 
understand why it is necessary to have libattr.so, libattr.so.1 and libattr.so.1.1.0 in /lib and have libattr.a, 
libattr.la and another libarrt.so symlink in /usr/lib.

Our project can not use the gnu build system because of this bug :(
Comment 2 Nalin Dahyabhai 2005-09-08 10:20:27 EDT
I think it might just be a packaging bug.  I tried moving the .la files for
libacl and libattr to /lib (where the shared libraries are), and the reproducer
ran just fine.
Comment 3 Peter O'Gorman 2005-09-08 10:36:43 EDT
Does not matter. We can not realistically put in a configure check for this and then ask users to su and 
move those files if running on fedora core or RHEL. For a start, the user may not be able to su. This bug 
has been sitting open for 5 months with zero activitity, we have a confusing makefile that tries to do much 
of the work of libtool which I want to change to use libtool ... but can't becuase we want to run on 
redhat ... makes me sad :(
Comment 4 Nalin Dahyabhai 2005-09-08 10:56:26 EDT
I'm not suggesting that users should move them -- I'm suggesting that the
package should place them in a different location.
Comment 5 Rob Braun 2005-09-08 10:57:23 EDT
RedHat support request 675074 also refers to this issue.
Comment 6 Bastien Nocera 2005-09-13 07:51:25 EDT
Removing the .la file is certainly the easiest way to solve this problem, and
forcing applications to link to /usr/lib/libattr.a (or better to
/usr/lib/libattr.so) directly.
Comment 7 Nalin Dahyabhai 2005-09-13 08:51:20 EDT
(In reply to comment #6)
> Removing the .la file is certainly the easiest way to solve this problem, and
> forcing applications to link to /usr/lib/libattr.a (or better to
> /usr/lib/libattr.so) directly.

If we go that route, keep in mind that we'll have to issue a new acl-devel
package either without libacl.la or rebuilt so that libacl.la references libattr.so.
Comment 8 Per Winkvist 2005-09-18 12:24:16 EDT
This has been annoying me for a while. I just modified /usr/lib/libacl.la 
 
# Libraries that this one depends upon. 
+ dependency_libs=' /usr/lib/libattr.la' 
- dependency_libs=' /lib/libattr.la' 
 
Now I can compile without problems. I also found a solution to this at: 
http://lists.kde.org/?l=kde-devel&m=112573027210577&w=2 
 
Comment 9 Peter O'Gorman 2005-09-19 10:14:40 EDT
Removal of the .la files is fine, libtool will happily find the .so's. As Nalin noted both packages will need to 
have the .la files removed. This solution os okay with me.

I am curious as to why these packages are configure'd with --prefix=/lib and then have bits installed in /
usr/lib and other bits in /lib. Is this a common thing? Does libtool need to search for .la files which don't 
exist at the absolute path specified in a .la file's dependency_libs?
Comment 10 Mary Ellen Foster 2005-09-21 08:39:56 EDT
NB: as a data point, it's been like this since at least Red Hat 9,
libattr-2.2.0-1, and libacl-2.2.3-1 (early 2003), because it's like that on my
desktop machine at work and it's currently preventing me from compiling KDE there.
Comment 11 Jon Burgess 2005-09-21 16:55:10 EDT
I get a similar problem with this library on FC4 X86-64:

$ grep libdir /usr/lib64/libacl.la
libdir='/lib64'
$ grep libdir /usr/lib64/libattr.la
libdir='/lib64'

Comment 12 Nalin Dahyabhai 2005-09-27 18:09:01 EDT
(In reply to comment #9)
> I am curious as to why these packages are configure'd with --prefix=/lib and
then have bits installed in /
> usr/lib and other bits in /lib. Is this a common thing? Does libtool need to
search for .la files which don't 
> exist at the absolute path specified in a .la file's dependency_libs?

This is typically done so that the development files are placed in the proper
locations (include files usually get installed to $prefix/include), but so that
the shared libraries can be available for use before /usr is mounted.
Comment 13 Ngo Than 2005-09-28 06:50:17 EDT
I have built attr-2.4.16-6 and acl-2.2.23-8 ,which does not include without *.la
files. Both are now in rawhide

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