Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 154146

Summary: libattr-devel provides .la file which creates dangling references to /lib/libattr.la
Product: [Fedora] Fedora Reporter: Nalin Dahyabhai <nalin>
Component: aclAssignee: Stephen Tweedie <sct>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bbraun, dag, jburgess777, mefoster, peter, pinskia
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-28 10:50:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 171114    

Description Nalin Dahyabhai 2005-04-07 19:08:22 UTC
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 12:53:38 UTC
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 14:20:27 UTC
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 14:36:43 UTC
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 14:56:26 UTC
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 14:57:23 UTC
RedHat support request 675074 also refers to this issue.

Comment 6 Bastien Nocera 2005-09-13 11:51:25 UTC
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 12:51:20 UTC
(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 16:24:16 UTC
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 14:14:40 UTC
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 12:39:56 UTC
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 20:55:10 UTC
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 22:09:01 UTC
(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 10:50:17 UTC
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