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

2009-08-15 Thread Ralf Wildenhues 
* Dave Korn wrote on Fri, Aug 14, 2009 at 03:21:33PM CEST:
 Eric Blake wrote:
  And beyond that, it's just lots of practice.  I agree that it often feels
  like you have to memorize loads of information to write portable shell,
  but at least these public reviews catch a lot of the pitfalls.
 
   Your cheat sheet will come in very handy :)  Thanks!

Forget the bash manual.  Read the SUSv3 man pages for sh etc., and the
  info Autoconf Portable Shell

chapter, plus maybe Paul Jarc's lintsh, and you're mostly set.

We try hard to document the deviations from Posix in autoconf.texi.

Cheers,
Ralf

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

2009-08-15 Thread Ralf Wildenhues 
in addition to what Eric already documented:

* Dave Korn wrote on Fri, Aug 14, 2009 at 01:34:18PM CEST:
 
   Still finishing it off and getting it tested, but while that's going, here's
 a preview of the path canonicalisation function as I've got it so far; let me
 know if I've done any major no-nos please!

Do you cope with paths starting with // (these can be special on Cygwin,
you may not remove the second / in that case)?  (If anything, this is
only a rather minor no-no however, and I have no idea whether we treat
it consistently elsewhere in libtool.)

 pathcar=s,^/\([^/]*\).*$,\1,
 pathcdr=s,^/[^/]*,,
 removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
 collapseslashes=s,/\+,/,g
 
 # func_normal_abspath path

Capitalize PATH here, please.  Maybe also s/PATH/FILE/ throughout the
comment, to avoid mistaking it with the $PATH environment variable?

 # Remove doubled-up and trailing slashes, . path components,
 # and cancel out any .. path components in PATH.
 # value returned in $func_normal_abspath_result

Missing a statement that an absolute path is returned, that would be
nice.

One would hope for a followup patch that factorizes all the forks
in this function for SUSv3 shells that provide ${var##...} etc.
Otherwise, if this function is used more than once per libtool
invocation, it will be a major speed bump in a typical build.
(IOW, you don't need to address this, but it ought to be looked at;
I might do it sometime.)

Cheers,
Ralf

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

2009-08-15 Thread Dave Korn 
Ralf Wildenhues wrote:
 in addition to what Eric already documented:
 
 * Dave Korn wrote on Fri, Aug 14, 2009 at 01:34:18PM CEST:
   Still finishing it off and getting it tested, but while that's going, 
 here's
 a preview of the path canonicalisation function as I've got it so far; let me
 know if I've done any major no-nos please!
 
 Do you cope with paths starting with // (these can be special on Cygwin,
 you may not remove the second / in that case)?  (If anything, this is
 only a rather minor no-no however, and I have no idea whether we treat
 it consistently elsewhere in libtool.)

  Hah.  I collapse them of course.  Doh.  I'll see how I can preserve them.

  The other possible problem is DOS-style paths.  I don't know if libtool is
supposed to handle them or not.  It certainly looks like
func_dirname_and_basename would fall down badly on them, but I don't know if
that's just a happenstance of the way it got autogenerated on my platform
where they aren't used?  I couldn't find anything in the manual referring to
drive letters.

 # func_normal_abspath path
 
 Capitalize PATH here, please.  Maybe also s/PATH/FILE/ throughout the
 comment, to avoid mistaking it with the $PATH environment variable?

  Will take the latter option.

 # Remove doubled-up and trailing slashes, . path components,
 # and cancel out any .. path components in PATH.
 # value returned in $func_normal_abspath_result
 
 Missing a statement that an absolute path is returned, that would be
 nice.

  Will add.  (The name of the function is supposed to be a hint, but it can't
hurt to be explicit!)

 One would hope for a followup patch that factorizes all the forks
 in this function for SUSv3 shells that provide ${var##...} etc.
 Otherwise, if this function is used more than once per libtool
 invocation, it will be a major speed bump in a typical build.
 (IOW, you don't need to address this, but it ought to be looked at;
 I might do it sometime.)

  Thanks, I still haven't learned all the internal structure of libtool and
wouldn't know how to do that without a bunch more research.

  Respin is nearly complete now, just these minor tweaks to get through and
give it some testing.  More later.

cheers,
  DaveK

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

2009-08-14 Thread Dave Korn 
Ralf Wildenhues wrote:

 So I guess we need to stick to host matching in the code, 

  Shame, but at least it makes my life slightly easier ;-)

  Still finishing it off and getting it tested, but while that's going, here's
a preview of the path canonicalisation function as I've got it so far; let me
know if I've done any major no-nos please!

cheers,
  DaveK

pathcar=s,^/\([^/]*\).*$,\1,
pathcdr=s,^/[^/]*,,
removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
collapseslashes=s,/\+,/,g

# func_normal_abspath path
# Remove doubled-up and trailing slashes, . path components,
# and cancel out any .. path components in PATH.
# value returned in $func_normal_abspath_result
func_normal_abspath ()
{
  # Start from root dir and reassemble the path.
  func_normal_abspath_result=
  func_normal_abspath_tpath=$1
  case $func_normal_abspath_tpath in
)
  # Empty path, that just means $cwd.
  func_stripname '' '/' `pwd`
  func_normal_abspath_result=$func_stripname_result
  return
;;
/*)
  # Absolute path, do nothing.
;;
*)
  # Relative path, prepend $cwd.
  func_normal_abspath_tpath=`pwd`/$func_normal_abspath_tpath
;;
  esac
  # Cancel out all the simple stuff to save iterations.
  func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
-e $removedotparts -e $collapseslashes`
  # We want the path to end with a slash for ease of parsing, and
  # doubled-up slashes won't hurt us here, so just add one on.
  func_normal_abspath_tpath=$func_normal_abspath_tpath/
  while :; do
func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | $SED \
-e $pathcar`
func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
-e $pathcdr`
# Figure out what to do with it
case $func_normal_abspath_tcomponent in
  )
# Trailing empty path component, ignore it.
  ;;
  ..)
# Parent dir; strip last assembled component from result.
func_dirname $func_normal_abspath_result
func_normal_abspath_result=$func_dirname_result
  ;;
  *)
# Actual path component, append it.

func_normal_abspath_result=$func_normal_abspath_result/$func_normal_abspath_tcomponent
  ;;
esac
# Processed it all yet?
if test $func_normal_abspath_tpath = / ; then
  # If we ascended to the root using .. the result may be empty now.
  if test -z $func_normal_abspath_result ; then
func_normal_abspath_result=/
  fi
  break
fi
  done
}

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

2009-08-14 Thread Dave Korn 
Eric Blake wrote:

 Cancelling out .. is wrong for 'symlink/..', when symlink does not
 necessarily point to a working directory exactly one level down.  (True,
 cygwin does not implement POSIX semantics here, and cancels out foo/..
 behind your back rather than properly resolving foo, but this function
 will need to work on all other systems that do it correctly).

  This is abspath, not realpath; it doesn't follow symlinks.  It has to work
before install time, there's no guarantee that any of the paths even exist.

   func_normal_abspath_tpath=$1
 
 Double-quoting not necessary here - variable assignment is already in a
 quoted context, and quotes are only needed to protect metacharacters.

   case $func_normal_abspath_tpath in
 
 Likewise - the case argument is already in a double-quoted context.

  Ok, but is it harmful?  I just prefer to quote always for simplicity and
AFAIK it can't hurt (in an ordinary direct execution context like this, it
might be different if I was assigning these commands as strings to variables
and trying to exec them later.)

 )
   # Empty path, that just means $cwd.
   func_stripname '' '/' `pwd`
 
 Can we rely on $PWD instead of forking a process?

  I don't know if it's supported by all the shells we have to support.  I'm
not too concerned with optimising the hell out of this, I want robustness
first, and it's not something that I think should need to be used more than a
couple of times during any given libtool invocation so I hope it's not a
significant overhead.

   func_normal_abspath_result=$func_stripname_result
   return
 ;;
 /*)
   # Absolute path, do nothing.
 
 Do we want to cater to DOS style absolute paths?  [a-z]:\\

  I don't, personally.  Does anything else in libtool handle them?  Does
libtool run on djgpp?  Eurgh, that's going to make life horribly complicated.
 I'm tempted to just bang a wrapper around the current function that spots a
dos path, strips off the driveletter-colon, converts to forward slashes, lets
the current code handle it as if it were a posix path, then converts the
slashes back and stitches the driveletter back on.

 ;;
   esac
   # Cancel out all the simple stuff to save iterations.
   func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
 -e $removedotparts -e $collapseslashes`
 
 I thought we were trying to move away from $ECHO and instead use the shell
 functions.

  I don't know, I copied func_dirname_and_basename.  I thought there's a
problem about backslashes being interpreted by some shell echos even in the
absence of -e?

  And you have a portability no-no, documented in the autoconf
 manual:
 
 a=``
 
 is non-portable, but can always be replaced by the portable:
 
 a=``
 
 See why I don't like spurious  around variable assignments?

  Ah, now I do.  Ok, but is some nice clear list of where you should and
shouldn't quote anywhere?  As far as I can tell you have to memorize the
entire bash manual and then infer what to do from all the overlapping sets of
expansions and contexts and rules.  Then you have to to the same for all the
other shells we're supposed to support.  Then you have to infer a set of
lowest-common-denominator rules from all of that.

   # We want the path to end with a slash for ease of parsing, and
   # doubled-up slashes won't hurt us here, so just add one on.
   func_normal_abspath_tpath=$func_normal_abspath_tpath/
   while :; do
 func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | 
 $SED \
 -e $pathcar`
 func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
 -e $pathcdr`
 
 Nit - I'd break these long lines at |, not after $SED, so that the entire
 sed command is on a single line.

  I took my cue from func_quote_for_expand, which made me think it would be at
least acceptable to do it this way, but if you're looking for a convention,
the libtool convention appears by overwhelming consensus to be not to wrap
ECHO ... | SED at all, even if the line is really long.

 $ grep -R 'ECHO.*SED' libltdl/ | wc -l
 591
 
 $ grep -R '| \$SED \\' libltdl/ | wc -l
 24
 
 $

cheers,
  DaveK

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

2009-08-14 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dave Korn on 8/14/2009 5:34 AM:
   Still finishing it off and getting it tested, but while that's going, here's
 a preview of the path canonicalisation function as I've got it so far; let me
 know if I've done any major no-nos please!

 pathcar=s,^/\([^/]*\).*$,\1,
 pathcdr=s,^/[^/]*,,
 removedotparts=s,/\(\.\(/\|$\)\)\+,/,g
 collapseslashes=s,/\+,/,g
 
 # func_normal_abspath path
 # Remove doubled-up and trailing slashes, . path components,
 # and cancel out any .. path components in PATH.

Cancelling out .. is wrong for 'symlink/..', when symlink does not
necessarily point to a working directory exactly one level down.  (True,
cygwin does not implement POSIX semantics here, and cancels out foo/..
behind your back rather than properly resolving foo, but this function
will need to work on all other systems that do it correctly).

   func_normal_abspath_tpath=$1

Double-quoting not necessary here - variable assignment is already in a
quoted context, and quotes are only needed to protect metacharacters.

   case $func_normal_abspath_tpath in

Likewise - the case argument is already in a double-quoted context.

 )
   # Empty path, that just means $cwd.
   func_stripname '' '/' `pwd`

Can we rely on $PWD instead of forking a process?

   func_normal_abspath_result=$func_stripname_result
   return
 ;;
 /*)
   # Absolute path, do nothing.

Do we want to cater to DOS style absolute paths?  [a-z]:\\

 ;;
 *)
   # Relative path, prepend $cwd.
   func_normal_abspath_tpath=`pwd`/$func_normal_abspath_tpath

Again, double quotes aren't necessary.

 ;;
   esac
   # Cancel out all the simple stuff to save iterations.
   func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
 -e $removedotparts -e $collapseslashes`

I thought we were trying to move away from $ECHO and instead use the shell
functions.  And you have a portability no-no, documented in the autoconf
manual:

a=``

is non-portable, but can always be replaced by the portable:

a=``

See why I don't like spurious  around variable assignments?

   # We want the path to end with a slash for ease of parsing, and
   # doubled-up slashes won't hurt us here, so just add one on.
   func_normal_abspath_tpath=$func_normal_abspath_tpath/
   while :; do
 func_normal_abspath_tcomponent=`$ECHO $func_normal_abspath_tpath | 
 $SED \
 -e $pathcar`
 func_normal_abspath_tpath=`$ECHO $func_normal_abspath_tpath | $SED \
 -e $pathcdr`

Nit - I'd break these long lines at |, not after $SED, so that the entire
sed command is on a single line.

 # Figure out what to do with it
 case $func_normal_abspath_tcomponent in
   )
 # Trailing empty path component, ignore it.
   ;;
   ..)
 # Parent dir; strip last assembled component from result.
   func_dirname $func_normal_abspath_result
   func_normal_abspath_result=$func_dirname_result
   ;;
   *)
 # Actual path component, append it.
 
 func_normal_abspath_result=$func_normal_abspath_result/$func_normal_abspath_tcomponent
   ;;
 esac
 # Processed it all yet?
 if test $func_normal_abspath_tpath = / ; then
   # If we ascended to the root using .. the result may be empty now.
   if test -z $func_normal_abspath_result ; then
 func_normal_abspath_result=/
   fi
   break
 fi
   done
 }

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqFV58ACgkQ84KuGfSFAYAGLwCeNF5H7L+noHCwyR6MDPwuFnTk
zJIAoMC0kyZtLZHd9bx4PX4m/J6pcF/O
=y3KX
-END PGP SIGNATURE-

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

2009-08-14 Thread Eric Blake 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dave Korn on 8/14/2009 7:11 AM:
 a=``

 is non-portable, but can always be replaced by the portable:

 a=``

 See why I don't like spurious  around variable assignments?
 
   Ah, now I do.  Ok, but is some nice clear list of where you should and
 shouldn't quote anywhere?  As far as I can tell you have to memorize the
 entire bash manual and then infer what to do from all the overlapping sets of
 expansions and contexts and rules.  Then you have to to the same for all the
 other shells we're supposed to support.  Then you have to infer a set of
 lowest-common-denominator rules from all of that.

I think it's as simple as:

if you are doing variable assignment, there is no word splitting, so you
only need quotes if it would otherwise look like multiple words:

a=$1
b=$1 $2

if you are doing case statements, there is no word splitting, so you only
need quotes if it would otherwise look like multiple words:

case $1 in
case  $1  in

if you are doing `` which needs embedded quoting, then it is only safe to
do it as variable assignment (where `` looks like a single word, without
needing outer ):

a=`echo $1 $2`

pretty much every where else, all $ expansions need double quotes if you
want to avoid word splitting (but using $ expansions to hide tool names is
one case where you DO want word splitting):

ECHO='printf %s\n'
$ECHO $1

And beyond that, it's just lots of practice.  I agree that it often feels
like you have to memorize loads of information to write portable shell,
but at least these public reviews catch a lot of the pitfalls.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqFYVAACgkQ84KuGfSFAYBIRwCgxRt0p2lnFnSfQOHl0TR1puou
rPoAoJsTLkaB4QMg6ZcTsD2bKqNWftfQ
=wagC
-END PGP SIGNATURE-

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

2009-08-14 Thread Dave Korn 
Eric Blake wrote:

 I think it's as simple as:

 And beyond that, it's just lots of practice.  I agree that it often feels
 like you have to memorize loads of information to write portable shell,
 but at least these public reviews catch a lot of the pitfalls.

  Your cheat sheet will come in very handy :)  Thanks!

cheers,
  DaveK

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

2009-08-13 Thread Peter Rosin 

Den 2009-08-11 12:30 skrev Dave Korn:

+AT_SETUP([dll basic test])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([main.c],[[
+extern int x;
+extern int y;
+
+int main() {
+return x+y;
+}
+]])


*snip*


+AT_SETUP([dll install to bindir])
+
+AT_DATA([foo.c],[[
+int x=0;
+]])
+
+AT_DATA([bar.c],[[
+extern int x;
+int bar(void);
+int bar() { return x;}
+]])
+
+AT_DATA([baz.c],[[
+int y=0;
+]])


Missed this before, sorry. But since it is a well known fact that
exporting variables from libraries are bad and should be avoioded,
can we please stop adding more of that practice to the test suite?
There is enough of it already and in case it fails, other failures
might be hidden.

Cheers,
Peter

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

2009-08-13 Thread Ralf Wildenhues 
* Ralf Wildenhues wrote on Thu, Aug 13, 2009 at 08:23:22AM CEST:
 * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
  --- a/doc/libtool.texi
  +++ b/doc/libtool.texi
  @@ -1376,6 +1376,15 @@ 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
  +When linking a DLL for Windows or another PE platform, this option tells
 
 What does this have to do with PE?  All this is about is that there is
 no real, independent $shlibpath_var beside PATH.

Erm, what I meant was that: this system provides no way to hard-code
library paths into executables, and also has no $shlibpath_var
independent of the PATH variable.  Sorry about that.

  I'm OK with mentioning
 that Windows is the sole current user of this, but please let's word
 this in a way that doesn't require us to change the interface if some
 other system requires it, too.  Ideally, neither the text.

  +for x in \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin/ \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/bin \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0/ \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/bin/ \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/bin \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin/ \
  +   ${curdir}/usr/lib/gcc/i686-pc-cygwin \
  +   ${curdir}/usr/lib/bin/ \
  +   ${curdir}/usr/lib/bin \
  +   ${curdir}/usr/bin/ \
  +   ${curdir}/usr/bin \
  +   ${curdir}/bin/ \
  +   ${curdir}/bin \

You don't test paths with a '../' component in it.  I thus assume they
won't work with your implementation (they work with gnulib-tool's).
These components often occur within GCC (haven't checked whether for
your particular situation, but I'd wonder why they shouldn't).

Cheers,
Ralf

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

2009-08-13 Thread Dave Korn 
Ralf Wildenhues wrote:
 Hello Dave,
 
 * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
   Well, the bindir option exists only to support PE DLLs,
 
 Bzzt.  First error.  If libtool provides -bindir, then it should accept
 it on every system, [ ... ]  Of course on non-PE
 systems, it should just ignore the option silently.

  That's exactly what it does already, as I thought I mentioned upthread.

 So it's only the PE-specific bits of the test that should be skipped on
 systems where they don't apply.
 
 Thus, bindir.at is a sensible name.  

  I can rename it and adjust the tests so they run on all platforms, but make
sure the library /doesn't/ get installed to bindir on non-PE platforms.  Ok?

 Do you intend for Automake to pass
 -bindir to libtool --mode=link invocations automatically (maybe for
 foo_LTLIBRARIES with foo not equal to lib or libexec)?

  I intend the maintainer to trivially add -bindir $(bindir) anywhere in
their makefiles that they would be adding -no-undefined to cause DLLs to be
built.  Sure I mentioned that one already, didn't I?

 * Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST:
   All rebuilt OK.  Checked docs with make dvi info pdf and viewing the
 generated file.  Testsuite re-run is still in progress, but I already checked
 that the new tests all still pass, so unless I post back saying otherwise in 
 the
 next couple of hours, assume the lot completed without regressions.
 
 Tested on what system(s)?

i686-pc-cygwin.  Could do a linux run as well if you like.

 BTW, even if the part going into GCC is covered by your GCC assignment,
 the rest is still sufficiently nontrivial to warrant an assignment.

  Gah, of course, forgot about the testcase.  Oh well, I didn't delay sending
off for the paperwork based on that theory, so we've not lost any time.

 diff --git a/Makefile.am b/Makefile.am
 old mode 100644
 new mode 100755
 
 Your files suffer from mode changes.  They are of course not acceptable,
 though I understand they are a w32 artifact.  Can git be made to ignore
 them for you?

  I have no idea what's going on here.  The modes of the files haven't changed
a bit according to 'ls', so cygwin git must be acting up.  If I was to end up
applying the patch myself I'd probably have to check out libtool on a linux
box and commit it there.

 tests/bindir.at, as already noted above; and as this is about
 'libtool' (the script) API, please sort it alongside the other API
 tests, preferably before or after cwrapper.at.  Thanks.

  Okeydokey; couldn't tell if there was a grouping and ordering in that list
or not.

 --- a/doc/libtool.texi
 +++ b/doc/libtool.texi
 @@ -1376,6 +1376,15 @@ 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
 +When linking a DLL for Windows or another PE platform, this option tells
 
 What does this have to do with PE?

  PE is the object file format.  There is no other object file format that has
DLLs, and no DSOs other than DLLs require installation to $PATH.  It would
seem strange to suggest that this would work with ELF DLLs on Linux, for
example, since there are no such things!

  All this is about is that there is
 no real, independent $shlibpath_var beside PATH.  I'm OK with mentioning
 that Windows is the sole current user of this, but please let's word
 this in a way that doesn't require us to change the interface if some
 other system requires it, too.  Ideally, neither the text.

  I really and honestly cannot imagine any other possible use case for this
functionality.  Still, if you want to suggest some more generic wording, just
tell me what you'd like it to say and I'll paste it in.

 +# func_relative_path libdir bindir
 +# generates a relative path from LIBDIR to BINDIR, intended
 +# for supporting installation of windows DLLs into -bindir.
 
 gnulib-tool has a function func_relativize.  Can we just reuse that
 (and make it fast)?  Failing that, did you write this function from
 scratch or took it from anywhere else.

  I wrote it from scratch, then Chuck showed me how to do the shell script
portability stuff on this list.  The tests cover all corner-cases and it works
and has no conceivable copyright or licensing snags.  I think those are
reasonable justifications to just use it as-is.

 I don't see any reason this function should be written specific to
 libdir and bindir.  There are other file names that may usefully be
 relativized, so the function should be as general as possible, and use
 generic names, too.

  Sure; I just picked those names as indicative, not normative, examples of
usage.  How about I change them to destdir and srcdir?

 +# call:
 +#   func_dirname:
 +# func_dirname file append nondir_replacement
 
 Why do you repeat the descriptions of these functions here again?
 That's not normally done elsewhere in

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

2009-08-13 Thread Dave Korn 
Ralf Wildenhues wrote:
 * Ralf Wildenhues wrote on Thu, Aug 13, 2009 at 08:23:22AM CEST:
 * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
 --- a/doc/libtool.texi
 +++ b/doc/libtool.texi
 @@ -1376,6 +1376,15 @@ 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
 +When linking a DLL for Windows or another PE platform, this option tells
 What does this have to do with PE?  All this is about is that there is
 no real, independent $shlibpath_var beside PATH.
 
 Erm, what I meant was that: this system provides no way to hard-code
 library paths into executables, and also has no $shlibpath_var
 independent of the PATH variable.  Sorry about that.

  Ah, see what you mean now; any other system with those properties would need
to have the libraries installed into a bindir where they could be found.  Do
you know of any such systems off the top of your head?

 You don't test paths with a '../' component in it.  I thus assume they
 won't work with your implementation (they work with gnulib-tool's).
 These components often occur within GCC (haven't checked whether for
 your particular situation, but I'd wonder why they shouldn't).

  Good point.  I'll add some and see what happens and fix any bugs arising
before I post the respin.  I'd better check for './' components too.

cheers,
  DaveK

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

2009-08-13 Thread Dave Korn 
Peter Rosin wrote:

 Missed this before, sorry. But since it is a well known fact that
 exporting variables from libraries are bad and should be avoioded,
 can we please stop adding more of that practice to the test suite?
 There is enough of it already and in case it fails, other failures
 might be hidden.

  It is?  I didn't know that.  I'll function-ify them.

cheers,
  DaveK

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

2009-08-13 Thread Ralf Wildenhues 
Hi Dave,

* Dave Korn wrote on Thu, Aug 13, 2009 at 04:10:11PM CEST:
 Ralf Wildenhues wrote:
  * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
Well, the bindir option exists only to support PE DLLs,
  
  Bzzt.  First error.  If libtool provides -bindir, then it should accept
  it on every system, [ ... ]  Of course on non-PE
  systems, it should just ignore the option silently.
 
   That's exactly what it does already, as I thought I mentioned upthread.

Yeah, I was merely arguing for the testsuite file name; sorry for the
confusion.

  So it's only the PE-specific bits of the test that should be skipped on
  systems where they don't apply.
  
  Thus, bindir.at is a sensible name.  
 
   I can rename it and adjust the tests so they run on all platforms, but make
 sure the library /doesn't/ get installed to bindir on non-PE platforms.  Ok?

Why would that additional test be necessary?

The general idea (however poorly executed) is that the test suite should
need as little adjustment as possible when we add support for new
platforms.  Likewise, ltmain should not require much adjustment except
to accommodate actually new semantics; only libtool.m4 and ltdl.m4
really ought to carry all the system-specifics, and they should be
transported into the libtool script through the bunch of variables.

Yes, this idea is pretty poorly executed ATM.

But in this particular case, I would argue that either you look at the
libtool variables shlibpath_var and hardcode_action for PATH and
unsupported.  And even then, I wouldn't really want to check for
presence of a particular file in $bindir, but I'd check whether a
program executable installed in $bindir, and linked against a library
(that should have its DLL installed in $bindir on applicable systems)
will start and run correctly.  Written this way, however, you don't
need to delimit this particular test to any subset of platforms: things
will work on any other system, too, by way of libtool linking semantics.

  Do you intend for Automake to pass
  -bindir to libtool --mode=link invocations automatically (maybe for
  foo_LTLIBRARIES with foo not equal to lib or libexec)?
 
   I intend the maintainer to trivially add -bindir $(bindir) anywhere in
 their makefiles that they would be adding -no-undefined to cause DLLs to be
 built.  Sure I mentioned that one already, didn't I?

Yes, you mentioned that.  What I meant was a followup semantic change
in Automake.  Assume a Makefile.am with

  lib_LTLIBRARIES = libfoo.la
  fooexecdir = $(libdir)/sub/subsub/bla
  fooexec_LTLIBRARIES = libbar.la

then automake will currently, while creating libfoo.la, add '-rpath
$(libdir)' to the link command line, and '-rpath $(fooexecdir)' to that
for libbar.la.  Now, automake could be smart and, when it does not see
the -module option being passed, either

1) add '-bindir $(bindir)' to none,
2) or both of these invocations, or
3) just to the one of libbar.la, knowing that the default relative from
   $(fooexecdir) to $(bindir) is not ../bin.

We have (1) now.  With (2), arbitrary --bindir and --libdir values
passed to configure by the user would be handled as well.  The question
is whether there can be cases when a developer would *not* want -bindir
to be passed automatically.

What do you think?  Even if there are such cases, we could arrange for
automake to output the -bindir before expanding $(LDFLAGS), so that it
would be overridable.

Of course Automake would only do any of this with a libtool that
understands -bindir.

  * Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST:
All rebuilt OK.  Checked docs with make dvi info pdf and viewing the
  generated file.  Testsuite re-run is still in progress, but I already 
  checked
  that the new tests all still pass, so unless I post back saying otherwise 
  in the
  next couple of hours, assume the lot completed without regressions.
  
  Tested on what system(s)?
 
 i686-pc-cygwin.  Could do a linux run as well if you like.

I think it would be good to see test results for MinGW and GNU/Linux,
but it's sufficient to run the new tests only,
  make check-local TESTSUITEFLAGS='-v -d -x -k bindir'

or so, depending on how you name your tests.  (I can run these tests.)

  diff --git a/Makefile.am b/Makefile.am
  old mode 100644
  new mode 100755
  
  Your files suffer from mode changes.  They are of course not acceptable,
  though I understand they are a w32 artifact.  Can git be made to ignore
  them for you?
 
   I have no idea what's going on here.  The modes of the files haven't changed
 a bit according to 'ls', so cygwin git must be acting up.  If I was to end up
 applying the patch myself I'd probably have to check out libtool on a linux
 box and commit it there.

OK.  It's no big deal, just a bit to remember to fix up after I apply
your patch.

  tests/bindir.at, as already noted above; and as this is about
  'libtool' (the script) API, please sort it alongside the other API
  tests, preferably before or after

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

2009-08-13 Thread Dave Korn 
Ralf Wildenhues wrote:

 Yeah, I was merely arguing for the testsuite file name; sorry for the
 confusion.

  NP.  Renamed to bindir.at.

   I can rename it and adjust the tests so they run on all platforms, but make
 sure the library /doesn't/ get installed to bindir on non-PE platforms.  Ok?
 
 Why would that additional test be necessary?
 
 The general idea (however poorly executed) is that the test suite should
 need as little adjustment as possible when we add support for new
 platforms.  Likewise, ltmain should not require much adjustment except
 to accommodate actually new semantics; only libtool.m4 and ltdl.m4
 really ought to carry all the system-specifics, and they should be
 transported into the libtool script through the bunch of variables.
 
 Yes, this idea is pretty poorly executed ATM.
 
 But in this particular case, I would argue that either you look at the
 libtool variables shlibpath_var and hardcode_action for PATH and
 unsupported.  And even then, I wouldn't really want to check for
 presence of a particular file in $bindir, but I'd check whether a
 program executable installed in $bindir, and linked against a library
 (that should have its DLL installed in $bindir on applicable systems)
 will start and run correctly.  Written this way, however, you don't
 need to delimit this particular test to any subset of platforms: things
 will work on any other system, too, by way of libtool linking semantics.

  Okay, I get what you mean.  I agree with the first part (using shlibpath_var
and hardcode_action rather than tests of specific OSs), but I beg to differ
about the second.  Checking if the program starts and runs correctly isn't
quite the same thing as checking if the parts were installed precisely where
the application coder instructed libtool to install them.  It's an indirect
test, and for instance would false positive if someone on a windows platform
had /lib in their PATH.  There might also be platforms where it didn't matter
functionally which of /bin and /lib a library got installed into, but there is
a packaging standard that says what goes where.  Now, okay we can always reset
the PATH for the test, but if we're trying to do something that works as-is
for unanticipated future systems, could we ever be sure we'd caught every
environment variable or whatever that might make this indirect test produce a
false result?

  For these reasons, I'd still prefer to test that the precise files we expect
get installed to the precise locations we require.  Doing it that way (but
with the first part of your suggestion) would still be fully cross-platform
and future-friendly, wouldn't it?

 Yes, you mentioned that.  What I meant was a followup semantic change
 in Automake.  Assume a Makefile.am with
   [ ... ]
 We have (1) now.  With (2), arbitrary --bindir and --libdir values
 passed to configure by the user would be handled as well.  The question
 is whether there can be cases when a developer would *not* want -bindir
 to be passed automatically.
 
 What do you think?  Even if there are such cases, we could arrange for
 automake to output the -bindir before expanding $(LDFLAGS), so that it
 would be overridable.

  The honest answer is I just haven't thought that far ahead yet.  I've only
been thinking of this option as a partner to -no-undefined, but you've
convinced me it might have relevance to a broader range of platforms.  In that
context, it quite possibly would make sense for Automake to start adding it
automatically.  But I haven't thought much about it yet.

 I think it would be good to see test results for MinGW and GNU/Linux,
 but it's sufficient to run the new tests only,
   make check-local TESTSUITEFLAGS='-v -d -x -k bindir'
 
 or so, depending on how you name your tests.  (I can run these tests.)

  Thanks, I'll take you up on that offer when the respin is complete.

 diff --git a/Makefile.am b/Makefile.am
 old mode 100644
 new mode 100755
 Your files suffer from mode changes.  

  I found a workaround.  I think the perm changes were in non-unixy parts of
the ACL and caused by using a windows native editor.  Copying correct perms
across from one of the other files in the same directory using 'chmod
--reference=...' shuts git up about the perms.

 Certainly.  My (arguably weak) point is that the Libtool manual is
 pretty generic; there is currently literally no mention of the terms PE
 or COFF at all, not even DLL is explained (note though that there is a
 pending patch from Chuck that documents some w32-specific issues).  It
 simply seems a bit of a jump to start off this way.  What about
 something like
 
   Pass the absolute name of the directory for installing executable
   programs (@pxref{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

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

2009-08-13 Thread Dave Korn 
Dave Korn wrote:

 +# func_relative_path libdir bindir
 
 gnulib-tool has a function func_relativize.  Can we just reuse that
 (and make it fast)?
 
 Sure.  However, if you want something that works with ../, then the
 gnulib-tool code is worth looking at.  Just a suggestion, you know.

  I'll write something to
 pre-condition the paths (i.e. remove '.' components and cancel out
 'component/..' pairs, remove any doubled-up slashes and trim any trailing one)
 and make it a separate func, it might come in handy elsewhere.

  Re that, BTW: can I use shell array variables portably?  I'm guessing not,
but it would simplify the design slightly if there was a way.

cheers,
  DaveK

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

2009-08-13 Thread Tim Rice 
On Thu, 13 Aug 2009, Dave Korn wrote:

   Re that, BTW: can I use shell array variables portably?  I'm guessing not,
 but it would simplify the design slightly if there was a way.

No, array variables are not portable.

-- 
Tim RiceMultitalents(707) 887-1469
t...@multitalents.net

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

2009-08-13 Thread Dave Korn 
Tim Rice wrote:
 On Thu, 13 Aug 2009, Dave Korn wrote:
 
   Re that, BTW: can I use shell array variables portably?  I'm guessing not,
 but it would simplify the design slightly if there was a way.
 
 No, array variables are not portable.
 

  g Sheer optimisim on my part.  Thanks for the reply.

cheers,
  DaveK

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

2009-08-13 Thread Ralf Wildenhues 
* Dave Korn wrote on Thu, Aug 13, 2009 at 09:19:49PM CEST:
 Ralf Wildenhues wrote:
 
I can rename it and adjust the tests so they run on all platforms, but 
  make
  sure the library /doesn't/ get installed to bindir on non-PE platforms.  
  Ok?
  
  Why would that additional test be necessary?
  
  The general idea (however poorly executed) is that the test suite should
  need as little adjustment as possible when we add support for new
  platforms.  Likewise, ltmain should not require much adjustment except
  to accommodate actually new semantics; only libtool.m4 and ltdl.m4
  really ought to carry all the system-specifics, and they should be
  transported into the libtool script through the bunch of variables.
  
  Yes, this idea is pretty poorly executed ATM.
  
  But in this particular case, I would argue that either you look at the
  libtool variables shlibpath_var and hardcode_action for PATH and
  unsupported.  And even then, I wouldn't really want to check for
  presence of a particular file in $bindir, but I'd check whether a
  program executable installed in $bindir, and linked against a library
  (that should have its DLL installed in $bindir on applicable systems)
  will start and run correctly.  Written this way, however, you don't
  need to delimit this particular test to any subset of platforms: things
  will work on any other system, too, by way of libtool linking semantics.
 
   Okay, I get what you mean.  I agree with the first part (using shlibpath_var
 and hardcode_action rather than tests of specific OSs), but I beg to differ
 about the second.  Checking if the program starts and runs correctly isn't
 quite the same thing as checking if the parts were installed precisely where
 the application coder instructed libtool to install them.

True.

  It's an indirect
 test, and for instance would false positive if someone on a windows platform
 had /lib in their PATH.  There might also be platforms where it didn't matter
 functionally which of /bin and /lib a library got installed into, but there is
 a packaging standard that says what goes where.  Now, okay we can always reset
 the PATH for the test, but if we're trying to do something that works as-is
 for unanticipated future systems, could we ever be sure we'd caught every
 environment variable or whatever that might make this indirect test produce a
 false result?

Probably not.

   For these reasons, I'd still prefer to test that the precise files we expect
 get installed to the precise locations we require.  Doing it that way (but
 with the first part of your suggestion) would still be fully cross-platform
 and future-friendly, wouldn't it?

Seems ok.  Thanks for persevering.

  Yes, you mentioned that.  What I meant was a followup semantic change
  in Automake.  Assume a Makefile.am with
[ ... ]
  We have (1) now.  With (2), arbitrary --bindir and --libdir values
  passed to configure by the user would be handled as well.  The question
  is whether there can be cases when a developer would *not* want -bindir
  to be passed automatically.
  
  What do you think?  Even if there are such cases, we could arrange for
  automake to output the -bindir before expanding $(LDFLAGS), so that it
  would be overridable.
 
   The honest answer is I just haven't thought that far ahead yet.  I've only
 been thinking of this option as a partner to -no-undefined, but you've
 convinced me it might have relevance to a broader range of platforms.  In that
 context, it quite possibly would make sense for Automake to start adding it
 automatically.  But I haven't thought much about it yet.

OK.  Anyway it's fine to deal with this later on.

Pass the absolute name of the directory for installing executable
programs (@pxref{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
@fi...@var{libdir}}.  You should not use @option{-bindir} for modules.
  
  Anyway, this is really just a suggestion and I appreciate your criticism
  of it.
 
   That seems fine for my purposes, I'll paste it in pretty much as-is, but the
 default parameter isn't necessarily libdir, it's just where-ever you've
 specified as the output path for the .la file + ../bin, isn't it?

Yeah; I tried to use @var{libdir} to indicate that (@var denotes a
metasyntactic variable, and renders differently) but that's probably too
subtle to understand, even with the for libraries installed to ...?
@var{libdir} is however the naming of the -rpath argument we use in
@node Link mode.

   I took a quick look

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

2009-08-13 Thread Dave Korn 
Ralf Wildenhues wrote:

 Seems ok.  Thanks for persevering.

  NP :)

 OK.  Well, can we compromise on _also_ having an executability test?
 There are always so many things that can go wrong for execution, that it
 is nonetheless useful to try that out, and for that, to have an
 executable that calls a function from the library.

  Absolutely fine by me; I'll code it that way.

cheers,
  DaveK

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

2009-08-13 Thread Dave Korn 
Ralf Wildenhues wrote:

 But in this particular case, I would argue that either you look at the
 libtool variables shlibpath_var and hardcode_action for PATH and
 unsupported.  

  On Cygwin, $hardcode_action = immediate in the generated libtool script.
Did you perhaps mean $hardcode_shlibpath_var, which is indeed unsupported?

cheers,
  DaveK

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

2009-08-13 Thread Ralf Wildenhues 
* Dave Korn wrote on Fri, Aug 14, 2009 at 04:30:27AM CEST:
 Ralf Wildenhues wrote:
 
  But in this particular case, I would argue that either you look at the
  libtool variables shlibpath_var and hardcode_action for PATH and
  unsupported.  
 
   On Cygwin, $hardcode_action = immediate in the generated libtool script.
 Did you perhaps mean $hardcode_shlibpath_var, which is indeed unsupported?

Oh brother, yes, I forgot about those bogus hardcode_libdir_flag_spec
settings.  They fool _LT_LINKER_HARDCODE_LIBPATH.  I don't remember
whether they were needed in order to not break some semantics in ltmain
(they probably were).

Anyway, $hardcode_action = immediate is definitely wrong, but fixing
that now is also way out of scope of this patch.  So I guess we need to
stick to host matching in the code, and work out a separate fix for the
setting of $hardcode_libdir_flag_spec.

Luckily at least my proposed text for the manual is written broadly
enough not to need changes due to this ...

Thanks,
Ralf

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

2009-08-12 Thread Dave Korn 
Dave Korn wrote:

 Now we twiddle our thumbs and wait for the paperwork, I guess!

  Hmm.  Or potentially not.  I just submitted the patch (backported to GCC's
forked libtool) to the gcc-patches list(*).  As far as I understand it, that
means I have now assigned my copyright in the patch to the FSF via my GCC
assign; or possibly I have expressed a willingness to assign my copyright
which would be completed by the patch being approved and committed; but either
way, the FSF now already is or is about to become the proper legal owner of
the copyright, no?

cheers,
  DaveK

-- 
(*) - http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00661.html

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

2009-08-12 Thread Ralf Wildenhues 
* Dave Korn wrote on Thu, Aug 13, 2009 at 12:50:22AM CEST:
 Dave Korn wrote:
 
  Now we twiddle our thumbs and wait for the paperwork, I guess!
 
   Hmm.  Or potentially not.

I'll have a review for the patch; at least for Libtool, it needs further
work.

Cheers,
Ralf

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

2009-08-11 Thread Dave Korn 

  Oops.  Forgot to change the test names when I renamed win32.at; fixed in this
revision.  Tests run to completion this time, with no regressions.

libtool/ChangeLog:

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

  And that, unless anyone has any more review comments, is the final revision.
Now we twiddle our thumbs and wait for the paperwork, I guess!

cheers,
  DaveK

diff --git a/Makefile.am b/Makefile.am
old mode 100644
new mode 100755
index a18955e..fdeeffd
--- a/Makefile.am
+++ b/Makefile.am
@@ -494,7 +494,8 @@ TESTSUITE_AT	= tests/testsuite.at \
 		  tests/configure-iface.at \
 		  tests/stresstest.at \
 		  tests/cmdline_wrap.at \
-		  tests/darwin.at
+		  tests/darwin.at \
+		  tests/pe-dll-inst-bindir.at
 
 EXTRA_DIST += $(srcdir)/$(TESTSUITE) $(TESTSUITE_AT) $(srcdir)/tests/package.m4
 
diff --git a/doc/libtool.texi b/doc/libtool.texi
old mode 100644
new mode 100755
index a7872c6..61a4e8e
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1376,6 +1376,15 @@ 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
+When linking a DLL for Windows or another PE platform, this option tells
+libtool where to eventually install the @samp{.dll} file. The output path
+is used to install the @samp{.la} control file, usually into a @samp{.../lib/}
+subdirectory of the @var{prefix}; except in the case of a dlopen()-able
+module (@pxref{Modules for libltdl}), it is usually desirable to install the
+DLL into a @samp{.../bin/} directory alongside. This option specifies the
+absolute path to the @var{bindir}.
+
 @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 +1469,10 @@ 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.  If @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} 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
old mode 100644
new mode 100755
index 4bc304c..496cac5
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -100,6 +100,76 @@ func_dirname_and_basename ()
 
 # Generated shell functions inserted here.
 
+# func_relative_path libdir bindir
+# generates a relative path from LIBDIR to BINDIR, intended
+# for supporting installation of windows DLLs into -bindir.
+# call:
+#   func_dirname:
+# func_dirname file append nondir_replacement
+# Compute the dirname of FILE.  If nonempty,
+# add APPEND to the result, otherwise set result
+# to NONDIR_REPLACEMENT.
+# value returned in $func_dirname_result
+#   func_stripname:
+# func_stripname prefix suffix name
+# Strip PREFIX and SUFFIX off of NAME. PREFIX and
+# SUFFIX must not contain globbing or regex special
+# characters, hashes, percent signs, but SUFFIX may
+# contain a leading dot (in which case that matches
+# only a dot).
+# value returned in $func_stripname_result
+func_relative_path ()
+{
+  func_relative_path_result=
+  func_stripname '' '/' $1
+  func_relative_path_tlibdir=$func_stripname_result
+  func_stripname '' '/' $2
+  func_relative_path_tbindir=$func_stripname_result
+
+  # Ascend the tree starting from libdir
+  while :; do
+# check if we have found a prefix of bindir
+case $func_relative_path_tbindir in
+  $func_relative_path_tlibdir*) # found a matching prefix
+	func_stripname $func_relative_path_tlibdir '' $func_relative_path_tbindir
+	func_relative_path_tcancelled=$func_stripname_result
+	if test -z $func_relative_path_result; then
+	  func_relative_path_result=.
+	fi
+	break
+	;;
+  *)
+	func_dirname $func_relative_path_tlibdir
+	func_relative_path_tlibdir=${func_dirname_result}
+	if test x$func_relative_path_tlibdir = x ; then
+	  # Have to descend all the way to the root!
+	  func_relative_path_result=../$func_relative_path_result
+