|
Bugzilla – Full Text Bug Listing |
| Summary: | libacl-devel: /usr/lib/libacl.la is a symlink to itself | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Bernhard Kaindl <bk> |
| Component: | Development | Assignee: | Andreas Gruenbacher <agruen> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | pascal.bleser, suse-beta |
| Version: | Beta 3.5internal | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | SuSE Linux 10.1 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Fix broken acl-devel symlinks
Fix broken symlink in libacl-devel package Fix broken symlinks in libattr-devel package. |
||
|
Description
Bernhard Kaindl
2006-02-10 13:42:51 UTC
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. *** |