Roumen Petrov wrote:
>>> I'm concerned that we can't implement a working portable(cross-platform)
>>> relative path calculation.
In the general case, Roumen, you are correct: there IS no portable
mechanism to compute relative paths when non-portable constructs such as
symbolic links are/may-be involved.
This is not the general case. This is a libtool- and DLL- specific
installation issue; we should not try to rewrite the entire auto* suite
to accommodate a wacky *hypothetical* installation tree organization not
currently supported by any GNU toolset, to fix one small corner case in
libtool.
Frankly, your hypothetical worry is not even a problem that libtool
should attempt to work around, for two reasons:
1) If the installation --prefix (AND DESTDIR/${prefix} as well!) is not
fully created PRIOR to build, then you cannot assume that when it IS
created, it will contain symbolic links, nor will you have ANY idea
where those future, hypothetical symbolic links will hypothetically
point to. So any attempt to use canonical_path or realpath (as opposed
to abspath) is doomed to failure, EVEN on those systems where (a)
realpath/canonical_path is supported, and (b) symbolic links are supported.
2) The current system is just as broken NOW, as libtool with Dave's fix
would be in your hypothetical case. In fact, the current system is EVEN
WORSE than any situation you have yet dreamed up. ../bin is WRONG, even
on non-symlink systems, even with pre-created installation trees, even
when they do or do not contain symlinks: if --bindir and --libdir are
not _exactly_ siblings under the same parent.
We've just been fortunate, because in 99.999% of the cases, --bindir and
--libdir ARE siblings, and are both directly under ${exec_prefix}.
Except for one, really BIG, exception: gcc (and three or four others
Yaakov has mentioned).
So, Dave's patch fixes the current problem, and does NOT make your
hypothetical (and completely unfixable anyway; see #1) case any worse.
The only possibility of fixing your complaint is to change the .la
format to specify the full absolute path to the dlname. Doing THAT
would, instead, break DESTDIR and GNU Coding Standard-required 'make
install prefix=${override_prefix}' installs, without a lot of additional
changes to the .la<->.lai installation process. And even then,
computing accurately these absolute paths and fully resolving any
hypothetical symbolic links would require the installation tree (whether
$(prefix), ${override_prefix}, or DESTDIR/${prefix}) to be fully created
prior to 'make'.
Not. Gonna. Happen.
If you can come up with a mechanism to use absolute paths in dlname,
which does not break any of the known installation modes, works whether
the installation tree(s) are pre-created or NOT, and whether the final
installation tree contains symlinks or NOT, AND solves the issue with
getting DLLs on w32 into the correct directory AND that the installed
.la file correctly describes its location...
Then please show us the code. And the test results. On as many systems
as Dave has, especially including mingw, cygwin, linux, and various
cross environments.
Oh, and please make sure you do all of this before the GCC 4.5 stage 1
development window closes, currently scheduled for the end of August.
Otherwise, please stop letting the "perfect" (IMO, the "perfectly
impossible") be the enemy of the good.
> :) :) :) Dave, you even don't understand what is wrong.
With respect, Roumen, I believe it is you that are misdiagnosing the
problem.
--
Chuck
