Bugzilla – Bug 149945
libacl-devel: /usr/lib/libacl.la is a symlink to itself
Last modified: 2006-03-20 12:38:28 UTC
rpm -qplv /work/CDs/all/full-i386/suse/i586/libacl-devel.rpm | grep la lrwxrwxrwx 1 root root 9 Feb 4 09:14 /usr/lib/libacl.la -> libacl.la It was discovered by trying to compile a package which uses libtool to link.
Thank you, Bernd. Nathan, this looks like a bug in include/buildmacros, right?
Hmm, not sure - it looks like its meant to be a symlink back to /lib/libacl.la (been awhile since I looked at this - it hasn't changed for eons) and the /lib prefix comes from @libdir@, which is a ./configure parameter (--libdir). By default (unless the SLES RPMS are running configure explicitly?), this would come from the "make configure" stage, which uses --libdir=/lib ... cheers.
Here's a fixed SUSE spec file. Note, this problem also probably exists in the attr packages - I'll take a look in a minute, and send a patch for those as well if needed. This seems to be a regression since SLES9, where these symlinks were OK. cheers.
Created attachment 70331 [details] Fix broken acl-devel symlinks
Created attachment 70333 [details] Fix broken symlink in libacl-devel package Fixes a missing piece from original patch, after looking at attr specfile. Also updates the changelog to display the bug number.
Created attachment 70334 [details] Fix broken symlinks in libattr-devel package. attr variant of previous acl spec patch - attr package is also affected.
Hmm, I think this would be bugs in the spec files. Thanks for still taking the time to look into this, Nathan. The patches make us end up with unnecessary libattr.so, libattr.a, and libattr.la symlinks in /lib[64] (and similar for libacl): the /lib[64] directory should only contain the files which are really necessary during boot; those are libattr.so.1 and libattr.so.1.1.0 right now. What do you think of dropping libattr.{a,la} from /lib[64], and moving the libattr.so symlink to /usr/lib[64] (to point to /lib[64]/libattr.so.1)?
|Hmm, I think this would be bugs in the spec files. Thanks for still taking the |time to look into this, Nathan. No problem. | What do you think of | dropping libattr.{a,la} from /lib[64], and moving the libattr.so symlink to | /usr/lib[64] (to point to /lib[64]/libattr.so.1)? Hmm, twas a very long time ago that we setup these install make targets, so my memory is getting hazy - but, I have a vague memory that doing this caused us to trip over some strange libtool behaviour, where having the libraries in two different places (/lib vs /usr/lib) caused the libtool .la files to be ignored and it wasn't possible to link statically... or something along those lines. It was a loong time ago though, and perhaps this is resolved nowadays in more recent libtool versions (although maybe not - once the linker finds a .so and no associated .a with it, not sure if it will keep looking even if -static is requested). Anyway, I do remember we had to put those symlinks there to workaround some problem (I think the above was _the_ problem), so removing them may introduce some oddball behaviour again. I dunno whats best here - I'll leave it to you guys to make that call. ;) cheers.
This bug also exists with libattr-2.4.24-2 on SL 10.0 (but not on <= 9.3). Could a fix be provided somehow ? Because a "real" libattr.a is missing completely, as it is overwritten by the symlink during makeinstall. It doesn't break building many packages, as I do a dozen every day and only noticed now, as it breaks dar ("Disk ARchiver", backup application) when trying to link a static binary. Thanks
This bug maybe being forgotten since its assigned to me and not someone @suse. I've supplied some patches to fix this, I'll pass this over to Andreas for now to decide on how to finally resolve it and get the fix merged into real builds. cheers.
It indeed was overlooked for a while. Fixed, thank you.
Ouch, this fix broke lots of packages: I also had to move /lib[64]/libacl.so and /lib[64]/libacl.la to /usr/lib[64} and remove the /lib[64]/libacl.a symlink. These files don't belong in /lib[64], they are only needed for development. The .la file included absolute paths, which I missed to fix up, so libtool started to fail for packages linking against libacl. Nothing seems to actually need the .la files and they only seem to cause trouble, so I'm removing them from the two packages.
*** Bug 159403 has been marked as a duplicate of this bug. ***