Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Charles Wilson wrote:
> Roumen Petrov wrote:
> > Dave Korn wrote:
> > > Roumen Petrov wrote:
[SNIP]

> 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?

The calculation or relative path to dll is based on function XXX_abspath 
that may produce wrong results. The algorithm to calculated absolute 
path is acceptable only for DOS like file systems.

Next implementation of -bindir flag may require changes in automake 
rule. Otherwise why will pass this flag to libtool ?
Next automake rule is not expected to create bindir, right ?

I'm not against to be removed current hard-coded libtoll '../bin/xx' DDL 
rule.
The Dave XX_abspath function for test case ported in previous my email 
produce "/work/tmp/test/test-links/b" (incorrect). Compare with command 
"readlink -f ../1/../". It is "/work/tmp/test/test-links/a" (correct !).

I'm concerned that we can't implement a working portable(cross-platform) 
relative path calculation.

What is better for "dlname" for installed la-file: absolute or relative 
path ?

May be is better to put DLL in bindir as is passed to libtool and to 
write in installed la-file as is ?


[SNIP]
> --
> Chuck

Roumen