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

[Ralf Wildenhues]

Hi Dave,

sorry for making you go through another round.

Except for the sed issues the following nits are all mechanical, and it
would suffice if you re-checked only your new tests and only on one of
the affected systems.

I consider the patch ready after this round, but I will probably leave a
couple of days for the w32 experts to comment on it, before applying it.

* Dave Korn wrote on Sun, Aug 16, 2009 at 02:55:22AM CEST:
  
  @item -R @var{libdir}
  If @var{output-file} is a program, add @var{libdir} to its run-time
 diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
 index 4bc304c..9954057 100644
 --- a/libltdl/config/general.m4sh
 +++ b/libltdl/config/general.m4sh
 @@ -100,6 +100,149 @@ func_dirname_and_basename ()
  
  # Generated shell functions inserted here.
  
 +pathcar=s,^/\([^/]*\).*$,\1,
 +pathcdr=s,^/[^/]*,,
 +removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
 +collapseslashes=s,/\+,/,g

\+ is a GNU sed extension, \{1,\} is Posix (two instances).
Nested \( \) are not portabled sed, neither are alternations \|.
Anchors $ inside groups are not portable.
The nesting probably works on most systems we care about, but if we can
avoid it then I'd prefer to do so.

(Sorry btw for completely overlooking this the last time.)

 +func_relative_path ()
 +{

 +  *)
 +func_dirname $func_relative_path_tlibdir
 +func_relative_path_tlibdir=${func_dirname_result}
 +if test x$func_relative_path_tlibdir = x ; then

Please double-quote $func_relative_path_tlibdir.  The rest of your patch
seems to cope with with spaces in file name components (even if the rest
of Libtool may not).

 --- /dev/null
 +++ b/tests/bindir.at

 +# These routines save the PATH before a test and restore it after,
 +# prepending a chosen directory to the path on the platforms where
 +# -bindir is needed after saving.
 +#
 +
 +func_save_and_prepend_path ()
 +{
 +  save_PATH=$PATH
 +  if $bindirneeded ; then
 +PATH=$1:$PATH
 +  fi
 +  export PATH
 +}
 +
 +func_restore_path ()
 +{
 +  PATH=$save_PATH

No 'export PATH' here?  (two instances)

 +}

 +# Check both static and shared versions run.  We don't install them
 +# here, that will be covered by the later tests; we've rpath'd things
 +# so that they can all be run in situ.
 +
 +AT_CHECK([$LIBTOOL --mode=execute ./main$EXEEXT], [], [stdout])

Please use LT_AT_NOINST_EXEC_CHECK here, to avoid error when cross
compiling.  Similar for the other executions of uninstalled programs.
(This macro is defined in tests/testsuite.at.)

 +# Ensure libraries can be found on PATH, if we are on one
 +# of the affected platforms, before testing the shared version.
 +
 +func_save_and_prepend_path $curdir/.libs
 +AT_CHECK([$LIBTOOL --mode=execute ./.libs/main$EXEEXT], [], [stdout])

eval `$LIBTOOL --config | grep '^objdir='`
func_save_and_prepend_path $curdir/$objdir
LT_AT_NOINST_EXEC_CHECK(... $objdir/...)

I'm afraid the direct execution of programs below .libs may not work
everywhere.  I'd have to check to be sure though.  It's fine with me
if you run this particular test only on systems of interest to you.

 +#  In fact, prepending the PATH as above is superfluous on the windows
 +# platforms that this feature is primarily aimed at, as the DLL search
 +# path always includes the directory from which the app was launched.
 +# To make sure it still works even when not side-by-side, we'll install
 +# the main executable and execute it from there while the PATH still
 +# points to the shared libs in the .libs subdir.  On other platforms,
 +# the rpaths we set at link time will guarantee it runs from the bindir.
 +
 +mkdir $curdir/bin
 +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
 $curdir/bin/main$EXEEXT], [], [ignore], [ignore])
 +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])

This one should work without $LIBTOOL --mode=execute prepended, no?
In that case, you could use LT_AT_EXEC_CHECK here, again, to avoid
spurious failures when cross compile testing.

If you care about the fact that an installed program does not
accidentally require, or search for, a library in an uninstalled
location, then you can, after the mode=install but before the execution,
clean up the files in the build tree, or even put a poisoned library
into the build tree.  I don't think either is necessary to do in this
test (at least the latter seems overkill, as we do it in other tests
already), but please decide for yourself.

 +AT_SETUP([bindir install tests])

 +curdir=`pwd`
 +for libdir in \
 + $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
 + $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
 + $curdir/usr/lib/ \
 + $curdir/usr/lib \
 + $curdir/baz \
 + $curdir/baz/lib/ ;

Mini nit: this ; is not necessary.  :-)

 +do
 +
 +  # Do a basic install with no -bindir option for reference.  We use the 
 sbin/
 +  # dir for the main exe to avoid the potential this only works because it's
 +  # side-by-side with the libs 

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

[Dave Korn]

Ralf Wildenhues wrote:
 Hi Dave,
 
 sorry for making you go through another round.

  :-/ That'll teach me to say unless there's anything else?

 +pathcar=s,^/\([^/]*\).*$,\1,
 +pathcdr=s,^/[^/]*,,
 +removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
 +collapseslashes=s,/\+,/,g
 
 \+ is a GNU sed extension, \{1,\} is Posix (two instances).
 Nested \( \) are not portabled sed, neither are alternations \|.

  Aaarrrgghh *headdesk* no alternations?  That's ... just ... it's
not even boolean!  Grrnashrollfoamgibber  Damn you, ATT!  Damn you, Sun!
 *shakes fist at crowd of greying bearded sandal-wearing old programmers*  See
you in hell, Unix-boys!  pulls pin out of a negated character class and
laughs maniacally

 Anchors $ inside groups are not portable.
 The nesting probably works on most systems we care about, but if we can
 avoid it then I'd prefer to do so.

  Okeydokey, simplified the SED scripts.

 +if test x$func_relative_path_tlibdir = x ; then
 
 Please double-quote $func_relative_path_tlibdir.  The rest of your patch
 seems to cope with with spaces in file name components (even if the rest
 of Libtool may not).

  Woops, yes, that was the intention, missed that one.  One more quick check
over all the quoting won't hurt while I'm at it.

 +func_restore_path ()
 +{
 +  PATH=$save_PATH
 
 No 'export PATH' here?  (two instances)

  So I reread the autoconf portable shell bit, found the bit about export, now
I know why it needs re-exporting each time it gets changed; will add the
missing directive.

 +AT_CHECK([$LIBTOOL --mode=execute ./main$EXEEXT], [], [stdout])
 
 Please use LT_AT_NOINST_EXEC_CHECK here, to avoid error when cross
 compiling.  Similar for the other executions of uninstalled programs.
 (This macro is defined in tests/testsuite.at.)

  Thanks for pointing me at it, can do.

 +# Ensure libraries can be found on PATH, if we are on one
 +# of the affected platforms, before testing the shared version.
 +
 +func_save_and_prepend_path $curdir/.libs
 +AT_CHECK([$LIBTOOL --mode=execute ./.libs/main$EXEEXT], [], [stdout])
 
 eval `$LIBTOOL --config | grep '^objdir='`
 func_save_and_prepend_path $curdir/$objdir
 LT_AT_NOINST_EXEC_CHECK(... $objdir/...)

  Ah, thanks, that beats hard-coding .libs/.

 I'm afraid the direct execution of programs below .libs may not work
 everywhere.  I'd have to check to be sure though.  It's fine with me
 if you run this particular test only on systems of interest to you.

  I think it's easier to just make it install the test executable.

  Also, gah!  Can't run a program because it's in a subdirectory?  What
kind of hare=brained system is that?  Would it help if I gave -rpath $objdir
when linking main as well as for the libs?

 +#  In fact, prepending the PATH as above is superfluous on the windows
 +# platforms that this feature is primarily aimed at, as the DLL search
 +# path always includes the directory from which the app was launched.
 +# To make sure it still works even when not side-by-side, we'll install
 +# the main executable and execute it from there while the PATH still
 +# points to the shared libs in the .libs subdir.  On other platforms,
 +# the rpaths we set at link time will guarantee it runs from the bindir.
 +
 +mkdir $curdir/bin
 +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
 $curdir/bin/main$EXEEXT], [], [ignore], [ignore])
 +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
 
 This one should work without $LIBTOOL --mode=execute prepended, no?

  I have no idea.  I just copied the only other things in the testsuite that I
could identify as execution tests.  What does it actually *do*?

 In that case, you could use LT_AT_EXEC_CHECK here, again, to avoid
 spurious failures when cross compile testing.

  Point taken.

 If you care about the fact that an installed program does not
 accidentally require, or search for, a library in an uninstalled
 location, then you can, after the mode=install but before the execution,
 clean up the files in the build tree, or even put a poisoned library
 into the build tree.  I don't think either is necessary to do in this
 test (at least the latter seems overkill, as we do it in other tests
 already), but please decide for yourself.

  Deleting the libs from the build tree seems easiest.

 +AT_SETUP([bindir install tests])
 
 +curdir=`pwd`
 +for libdir in \
 +$curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
 +$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
 +$curdir/usr/lib/ \
 +$curdir/usr/lib \
 +$curdir/baz \
 +$curdir/baz/lib/ ;
 
 Mini nit: this ; is not necessary.  :-)

  It's still valid, isn't it?  I don't like to make my syntax in a way that
only works because of line breaks.

 +  AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC -no-undefined -shared -o 
 libfoo.la $CPPFLAGS $CFLAGS $LDFLAGS foo.lo bar.lo baz.lo -rpath 
 $libdir],[0],[ignore],[ignore])
 
 Please drop -shared, it should be unnecessary.

  Ok, will do.

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

[Ralf Wildenhues]

* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
 Ralf Wildenhues wrote:
  sorry for making you go through another round.
 
   :-/ That'll teach me to say unless there's anything else?

Hehe.

  \+ is a GNU sed extension, \{1,\} is Posix (two instances).
  Nested \( \) are not portabled sed, neither are alternations \|.
 
   Aaarrrgghh *headdesk* no alternations?  That's ... just ... it's
 not even boolean!  Grrnashrollfoamgibber  Damn you, ATT!  Damn you, Sun!
  *shakes fist at crowd of greying bearded sandal-wearing old programmers*  See
 you in hell, Unix-boys!  pulls pin out of a negated character class and
 laughs maniacally

It's still Turing complete, so nothing that can't be worked around ...
;-

  I'm afraid the direct execution of programs below .libs may not work
  everywhere.  I'd have to check to be sure though.  It's fine with me
  if you run this particular test only on systems of interest to you.
 
   I think it's easier to just make it install the test executable.
 
   Also, gah!  Can't run a program because it's in a subdirectory?

No, that's not the reason.  The reason is the following: we don't always
try to make the uninstalled executables have hardcoded rpaths against
the uninstalled libraries: that would require us to relink at
installation time.  On some systems, you can --{en,dis}able-fast-install
to state you preference over relinking at make install time vs.
relinnking at mode=execute uninstalled-program time.  In the latter
case, it's the wrapper script/executable outside of the .libs directory
that provides for the machinery.

Your direct execution of .libs/main then by-passes that machinery.

  What
 kind of hare=brained system is that?  Would it help if I gave -rpath $objdir
 when linking main as well as for the libs?

Naa, don't do that, that's totally against the intention.

  +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
  $curdir/bin/main$EXEEXT], [], [ignore], [ignore])
  +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
  
  This one should work without $LIBTOOL --mode=execute prepended, no?
 
   I have no idea.  I just copied the only other things in the testsuite that I
 could identify as execution tests.  What does it actually *do*?

Run an installed program.  Installed programs ought to run without
$LIBTOOL prepended.

  +AT_SETUP([bindir install tests])
  
  +curdir=`pwd`
  +for libdir in \
  +  $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
  +  $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
  +  $curdir/usr/lib/ \
  +  $curdir/usr/lib \
  +  $curdir/baz \
  +  $curdir/baz/lib/ ;
  
  Mini nit: this ; is not necessary.  :-)
 
   It's still valid, isn't it?

Yes.

  I don't like to make my syntax in a way that
 only works because of line breaks.

OK, leave it like it is.

  Out of curiosity, which of the systems of interest creates a
  libfoo.so.0 file?  
 
   Linux.

But you're not interested in testing GNU/Linux with $bindirneeded.
Neither any of the other unices, which might not have a libfoo.so.0,
but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so
or libfoo.so.0.0 or whatnot.  So make life easy here, and drop all the
.so thingy tests, you don't want them here.  Thanks.

  What if that is a symlink rather than a plain file
  (test -f only tests for plain files)?
 
   It is.  The test still passes.  H. better take a closer look at
 that.  (And use the full so.0.0.0 name in the test).

Yeah, that's due to $bindirneeded.

  +# Clear any old stuff out before we install.  Because bindir
  +# may be in /tmp, we have to take care to create it securely
  +# and not to delete and recreate it if we do.
  +rm -rf $libdir $curdir/bin $curdir/sbin $curdir/baz $curdir/usr 
  2/dev/null
  
  I'd drop the 2/dev/null; let's see errors in the log.
 
   It makes a load of ugly noise when it tries to delete
 $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//., but I
 guess it's better that than missing something important.

Thanks.

Cheers,
Ralf

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

[Roumen Petrov]

Dave Korn wrote:

  So, here I hope is the final respin.  Built and tested on i686-pc-cygwin and
i686-pc-linux-gnu with no regressions and all new tests passing (see below sig
separator for details).

libtool/ChangeLog:

* Makefile.am (TESTSUITE_AT): Add bindir.at.
* libltdl/config/general.m4sh (func_normal_abspath): New function.
(func_relative_path): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): Accept new -bindir
option and use it, if supplied, to place Windows DLLs.
* tests/bindir.at: New file for DLL install tests.
* doc/libtool.texi (Link Mode): Update documentation.

  Unless I've missed anything?


I think that processing of '..' in a path is too naive. It will fail to 
produce correct results on filesystems with links.



cheers,
  DaveK



Roumen

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

[Dave Korn]

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.

  I think the whole of GNU configure expects the tree under $prefix/ to be
real and there are a lot of other things that will break if you try to use
symlinks to make the physical directory structure different from the apparent
structure, for example gcc tries to execute ld by starting at the
$prefix/lib/gcc/$target/$version directory where cc1 lives and invoking
../../../../bin/ld; if you've got symlinks in there that can't be ascended
without ending up somewhere other than you expect, then the compiler isn't
going to work.

  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?

cheers,
  DaveK

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

[Dave Korn]

Ralf Wildenhues wrote:
 * Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:

 +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
 $curdir/bin/main$EXEEXT], [], [ignore], [ignore])
 +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
 This one should work without $LIBTOOL --mode=execute prepended, no?
   I have no idea.  I just copied the only other things in the testsuite that 
 I
 could identify as execution tests.  What does it actually *do*?
 
 Run an installed program.  Installed programs ought to run without
 $LIBTOOL prepended.

  Did you mean Run an *un*installed program in the first part of that?  I'll
assume so.

 Out of curiosity, which of the systems of interest creates a
 libfoo.so.0 file?  
   Linux.
 
 But you're not interested in testing GNU/Linux with $bindirneeded.
 Neither any of the other unices, which might not have a libfoo.so.0,
 but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so
 or libfoo.so.0.0 or whatnot.  So make life easy here, and drop all the
 .so thingy tests, you don't want them here.  Thanks.

  But I do want to make sure the file went to the right place, or at the very
least, that it did *not* go to the -bindir.  Hmm.  I can't easily use a
pattern match either as it might match more than one file and confuse the test
-f syntax.  Guess I'll have to `ls *foo*0*` them and test -z the output, that
should work.

 What if that is a symlink rather than a plain file
 (test -f only tests for plain files)?
   It is.  The test still passes.  H. better take a closer look at
 that.  (And use the full so.0.0.0 name in the test).
 
 Yeah, that's due to $bindirneeded.

  But that just makes it test -f for the same name in a different directory,
so it still ought to fail.  It turns out that, at least for bash on my Fedora
10 VM, test -f works for symlinks:

 [da...@ubique .libs]$ if test -f libfoo.so.0 ; then echo yes ; else echo no ; 
 fi
 yes
 [da...@ubique .libs]$ if test -f libfoo.so.0.0.0 ; then echo yes ; else echo 
 no ; fi
 yes
 [da...@ubique .libs]$ ls -la libfoo.so.0*
 lrwxrwxrwx 1 davek davek   15 2009-08-16 20:55 libfoo.so.0 - libfoo.so.0.0.0
 -rwxrwxr-x 1 davek davek 5425 2009-08-16 20:55 libfoo.so.0.0.0
 [da...@ubique .libs]$ echo $BASH_VERSION 
 3.2.39(1)-release
 [da...@ubique .libs]$ 

  Weird.  Anyway, I won't rely on it.

cheers,
  DaveK

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

[Dave Korn]

Dave Korn wrote:
 Guess I'll have to `ls *foo*0*` them and test -z the output, that
 should work.

  Nope, may have whitespace.  Is checking the return status of ls portable?

cheers,
  DaveK

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

[Roumen Petrov]

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:

(
P=/work/tmp/test/test-links
rm -rf $P
mkdir $P
cd $P
mkdir -p a/1/2
mkdir -p b/2
(cd b; ln -s ../a/1)

cd b/2
D=../1/../
touch $D/test
func_normal_abspath $D
echo $func_normal_abspath_result
/bin/ls -l $func_normal_abspath_result/
/bin/ls -l $D
)



  I think the whole of GNU configure expects the tree under $prefix/ to be
real and there are a lot of other things that will break if you try to use
symlinks to make the physical directory structure different from the apparent
structure, for example gcc tries to execute ld by starting at the
$prefix/lib/gcc/$target/$version directory where cc1 lives and invoking
../../../../bin/ld; if you've got symlinks in there that can't be ascended
without ending up somewhere other than you expect, then the compiler isn't
going to work.


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  ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1  ./i486-mingw32/libexec - ../libexec/



  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.



cheers,
  DaveK


Roumen

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

[Charles Wilson]

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  ./i486-mingw32/lib/gcc - ../../lib/gcc/
 # l ./i486-mingw32/libexec
 lrwxrwxrwx 1  ./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

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

[Dave Korn]

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.

   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, 
   ^

 You may test you function with following example:

  No thanks, I don't think I'll bother.  I understand perfectly well what the
problem is with symlinks, but what you seem to overlook is that there is no
possible way of knowing whether any path component will be a real directory or
a symlink *before it is even created*.

 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.

  Yes, like I told you, the whole of GNU autotools and configure and
everything assumes that you won't be messing around with symlinks in your
$prefix structure like this.  What you are doing is unsupported.

 To resolve issue I use following additional links:
 # cd $PREFIX
 # l ./i486-mingw32/lib/gcc
 lrwxrwxrwx 1  ./i486-mingw32/lib/gcc - ../../lib/gcc/
 # l ./i486-mingw32/libexec
 lrwxrwxrwx 1  ./i486-mingw32/libexec - ../libexec/
 
 
   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.

  Since what you want is impossible in the general case, I'm not going to put
any effort into making your system work.  If you want to implement this
entirely new feature, you will have to patch autoconf, automake, gcc, libtool,
and everything else yourself.

cheers,
  DaveK

[PATCH, take 5][cygwin|mingw] Control where win32 DLLs get installed.

[Dave Korn]

  Fifth time lucky!  (Why do I say these things, I'm only asking for trouble!)

libtool/ChangeLog:

* Makefile.am (TESTSUITE_AT): Add bindir.at.
* libltdl/config/general.m4sh (func_normal_abspath): New function.
(func_relative_path): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_help): Document -bindir.
(func_mode_link): Accept new -bindir option and use it, if
supplied, to place Windows DLLs.
* tests/bindir.at: New file for install tests using -bindir.
* doc/libtool.texi (Link Mode): Update documentation.

  Built and tested on i686-pc-cygwin and i686-pc-linux-gnu with no regressions
and all new tests passing.  Ok now?

cheers,
  DaveK

-- 

All 124 tests passed

## - ##
## Test results. ##
## - ##

89 tests behaved as expected.
2 tests were skipped.
[da...@ubique libtool]$ ./libltdl/config/config.guess
i686-pc-linux-gnu
[da...@ubique libtool]$ uname -a
Linux ubique.localdomain 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23
23:37:54 EDT 2009 i686 athlon i386 GNU/Linux
[da...@ubique libtool]$
-- 
==
All 122 tests passed
(2 tests were not run)
==
 39: bindir compile checkok
 40: bindir basic lib test   ok
 41: bindir install testsok
## - ##
## Test results. ##
## - ##
85 tests behaved as expected.
6 tests were skipped.

ad...@ubik /gnu/libtool/libtool
$ ./libltdl/config/config.guess
i686-pc-cygwin

ad...@ubik /gnu/libtool/libtool
$ uname -a
CYGWIN_NT-5.0 ubik 1.7.0(0.212/5/3) 2009-08-12 20:18 i686 Cygwin

ad...@ubik /gnu/libtool/libtool
diff --git a/Makefile.am b/Makefile.am
index a18955e..d68ed33 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -468,6 +468,7 @@ TESTSUITE_AT	= tests/testsuite.at \
 		  tests/indirect_deps.at \
 		  tests/archive-in-archive.at \
 		  tests/execute-mode.at \
+		  tests/bindir.at \
 		  tests/cwrapper.at \
 		  tests/infer-tag.at \
 		  tests/localization.at \
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a7872c6..f862217 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,18 @@ Tries to avoid versioning (@pxref{Versioning}) for libraries and modules,
 i.e.@: no version information is stored and no symbolic links are created.
 If the platform requires versioning, this option has no effect.
 
+...@item -bindir
+Pass the absolute name of the directory for installing executable
+programs (@pxref{Directory Variables, , Directory Variables, standards,
+The GNU Coding Standards}).  @command{libtool} may use this value to
+install shared libraries there on systems that do not provide for any
+library hardcoding and use the directory of a program and the @env{PATH}
+variable as library search path.  This is typically used for DLLs on
+Windows or other systems using the PE (Portable Executable) format.
+On other systems, @option{-bindir} is ignored.  The default value used
+is @fi...@var{libdir}/../bin} for libraries installed to
+...@file{@var{libdir}}.  You should not use @option{-bindir} for modules.
+
 @item -dlopen @var{file}
 Same as @option{-dlpreopen @var{file}}, if native dlopening is not
 supported on the host platform (@pxref{Dlopened modules}) or if
@@ -1460,7 +1472,12 @@ the @option{-version-info} flag instead (@pxref{Versioning}).
 @item -rpath @var{libdir}
 If @var{output-file} is a library, it will eventually be installed in
 @var{libdir}.  If @var{output-file} is a program, add @var{libdir} to
-the run-time path of the program.
+the run-time path of the program.  On platforms that don't support
+hardcoding library paths into executables and only search PATH for
+shared libraries, such as when @var{output-file} is a Windows (or
+other PE platform) DLL, the @samp{.la} control file will be installed in
+...@var{libdir}, but see @option{-bindir} above for the eventual destination
+of the @samp{.dll} or other library file itself.
 
 @item -R @var{libdir}
 If @var{output-file} is a program, add @var{libdir} to its run-time
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..c751629 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -100,6 +100,151 @@ func_dirname_and_basename ()
 
 # Generated shell functions inserted here.
 
+# These SED scripts presuppose an absolute path with a trailing slash.
+pathcar=s,^/\([^/]*\).*$,\1,
+pathcdr=s,^/[^/]*,,
+removedotparts=s,/\(\./\)\{1\,\},/,g;s,/\.$,/,
+collapseslashes=s,/\{1\,\},/,g
+finalslash=s,/*$,/,
+
+# func_normal_abspath PATH
+# Remove doubled-up and trailing slashes, . path components,
+# and cancel out any .. path components in PATH after making
+# it an absolute path.
+# value returned in $func_normal_abspath_result
+func_normal_abspath ()
+{
+  # Start from root dir and reassemble the path.
+  func_normal_abspath_result=
+