Roumen Petrov wrote:
> Dave Korn wrote:
>> Roumen Petrov wrote:
>>> I think that processing of '..' in a path is too naive. It will fail to
>>> produce correct results on filesystems with links.
>>
>> As I explained to Eric, this function implements 'abspath', not
>> 'realpath',
>> and given that we can't assume any of the directories even exist when
>> we have
>> to do this at link time, before installation, I don't see how we could
>> hope to
>> do any different.
>
> You may test you function with following example:
> ----------------------------------------
[snip]
> )
> ----------------------------------------
Yes, it is clear that there are cases, with oddly-constructed
pre-existing trees that contain symlinks, where abspath != realpath.
But, keep your eye on the ball: right now DLLs get installed into the
wrong directory, even in relatively normal setups:
--libdir=/usr/lib/subdir/
(--bindir=/usr/bin)
Current behavior assumes that "bindir" (e.g., where the DLL actually
gets installed) is /usr/lib/subdir/../bin. This is clearly wrong, and
broken regardless of whether you have an odd symlink-infested /usr. The
existing logic basically only works if both bindir and libdir are the
defaults, AND there are no funky symlinks.
So...
Dave's patch doesn't make things any worse than they already are for
non-default libdir/bindir, even for symlink-infested installation trees.
Broken before, fixed after, unless bad symlink problems -- in which
case it MAY still be broken, and maybe NOT. But if you're mucking about
with symlinks to make the logical installation tree differ from the
physical installation tree, well...IMO you're just asking for trouble.
But it's not fair to Dave to ask him to solve ALL pre-existing problems
with libtool's installation logic. He's trying to solve one problem,
while (hopefully) at the same time not making other pre-existing
problems worse.
I think his patch satisfies those requirements.
> Sure.
> Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non
> prefixed binaries from <PREFIX>/<TARGET>/bin don't work for me. As
> example gcc can't find cc1. May be is same issue.
>
> To resolve issue I use following additional links:
> # cd $PREFIX
> # l ./i486-mingw32/lib/gcc
> lrwxrwxrwx 1 XXXX ./i486-mingw32/lib/gcc -> ../../lib/gcc/
> # l ./i486-mingw32/libexec
> lrwxrwxrwx 1 XXXX ./i486-mingw32/libexec -> ../libexec/
So...you're saying that gcc's installation paths are somewhat busted in
that the driver executables can't locate the backend executables, when
cross + non-default-prefix + odd-symlink-structure? OK.
So, why is this relevant to changes that *Dave* needs to make in the
patch for *libtool* with regards to *DLLs*? (Unless, you're simply
agreeing with Dave's statement that "yeah, lots of GNU-style
installations can break when you muck with the installation tree in
unsupported ways". But if so, then...what's the objection to Dave's
patch, again?)
>> So I don't think this is likely to cause any problem except in really
>> bizarre corner-cases where someone's already trying something dubious,
>> is it?
>
> So to me function like XX_abspath has to work.
Why? abspath != realpath. That's the point. If you're arguing that
all GNU installation tools should use realpath to canonicalize all paths
before use, well...maybe that discussion should be held, in some other
thread with a broader audience as it affects MUCH more than just
libtool. But (a) your desired behavior is not the case now, in a lot of
places other than libtool, (b) doing it your way will badly break
DESTDIR installations and any installation where the target installation
directory tree is not fully created at build/installation time (c) and
you'll get a lot of pushback from automake/autoconf on that.
Summary: in what way does Dave's patch make libtool behavior worse than
current? Given that I don't believe it does, yet his patch definitely
fixes issues that occur at present in much more common contexts, I'm
trying to clarify whether you believe your comments represent a reason
to block until rework, or accept as-is, Dave's current patch.
--
Chuck
