Bug#268140: libffi.la: wrong libdir setting
Scott James Remnant <scott@netsplit.com> writes:
> On Thu, 2004-08-26 at 13:39 +0200, Goswin von Brederlow wrote:
>
>> Scott James Remnant <scott@netsplit.com> writes:
>>
>> > On Thu, 2004-08-26 at 02:48 -0700, Debian Bug Tracking System wrote:
>> >
>> >> then libtool should be fixed. there is no documented requirement that
>> >> the path has to be normalized.
>> >>
>> > While there's no specifically documented requirement, there is a common
>> > sense one. Libtool doesn't make any attempt to normalise the paths
>> > given to it, in fact it's kinda a tricky issue ... for example:
>> >
>> > If you used -rpath /usr/mylib and that was a symlink to /usr/lib, would
>> > you expect that to be RPATHd or not?
>>
>> /usr/mylib is normalized while not being canonical on your system.
>>
>> I would expect . and .. to get removed while links are not removed if
>> libtool is to do any normalization.
_if_
> Why? If they were important enough to put in there, they must be useful
> for something.
>
> I actually fixed the dpkg-shlibdeps side of this (being over-sensitive
> to non-normalised paths) last week:
>
> http://arch.netsplit.com/scott@netsplit.com--2004/dpkg--devo--1.10--patch-40
|* scripts/dpkg-shlibdeps.pl: Normalise paths taken from ldd to strip
|cruft like /./ from them, as well as rpath-esque lib/../other-lib
|paths. Check each path component for symlinks to directories and if
|we find them, read them to get the real paths and give those to dpkg.
Now you broken setups where any component of /lib, /usr/lib or
/usr/X11R6/lib is a symlink to somewhere else. You can't just follow
links and give the result to dpkg. The only thing that works reliable
is to see if the path from the binary and the path from dpkg end up
pointing to the same file, which is an insane amount of work.
What might work well enough is to get the canonical path for the
default lib dirs, normalize the path/file in question and unnormalize
the path if it's the same as one of the lib paths (which might result
in more than one option).
> It was needed for AMD64's /usr/lib madness.
News to me. Afaik the only thing being affected by this so far is the
libffi.la file with its un-normalized path.
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
MfG
Goswin
PS: You could also resolve this by adding a requirement for paths to
be normalized.
Reply to: