Re: [cygwin] cwrapper emits wrapper script

[Ralf Wildenhues]

* Charles Wilson wrote on Tue, Apr 24, 2007 at 04:34:41AM CEST:
> Ralf Wildenhues wrote:
>
>> (note I'm not asking you to do this work here; actually, I'd like to ask
>> you not to fix even more different things with one patch.  Merely noting
>> it in case you're interested.)
>
> Ok, but it my defense: NOT fixing the mingw case (e.g. leaving the 
> wrapper.exe broken on mingw) + eliminate the wrapper script from '.' == 
> break EVERYTHING on mingw.  So, I kinda HAD to address this: and two 
> patches that touch exactly the same region of code is rather silly.

Certainly.  I was merely trying to not infer that you'd have to do even
more work than the lot that you're already doing.  Of course if you're
ambitious go for it.  ;-)

Thanks for fixing the MinGW case here.

>> Hmm, maybe one after the `rm -f "$prefix/bin/..."' and one after the
>> `$MAKE uninstall' line?
>
> Tabled.  Don't want to tackle more than one thing in a patch, you know. 

Yes, but that particular two-line change could go in before everything
else, given that it fixes the failure.

>> (Not sure about this WRAPPER_SCRIPT_BELONGS_IN_OBJDIR thing yet.)
>
> What's not to like?  A wrapper script that lives in $objdir *must* behave 
> ever-so-slightly differently from a wrapper script that lives in $objdir/.. 
> -- they must compute the location of the target executable. Couple that 
> with wanting to use the same func_emit_wrapper_script() method in both 
> cases...

Yes, yes.  I was thinking out loud and it was late...

>>> -# define DEBUG(format, ...)
>>> +# define LTWRAPPER_DEBUGPRINTF(format, ...)
>> What's the reason for this change?
>
> Because I've always felt really stupid about my original choice: using the 
> incredibly common "DEBUG" symbol as a function-like macro? What was I 
> smoking?

Hmm.  OK.  But since you undefine DEBUG anyway (and you've kept that for
the changed macro), there was no underlying problem here, no?  Anyway,
keeping this change is fine.

>> or by multiple -e.  Also, after a pipe (|), there's no need to escape
>> the newline.
>>> +   $ECHO ";"
>> Please use plain `echo' here.  $ECHO is for stuff that can contain \t,
>> begin with -n, and the like.
>
> oookay.

This is because $ECHO can be much much more expensive than echo, forking
and all.  Not on w32 especially (unless you happen to use a shell such
as dash), but in general, yes.

>>> +if (strncmp(argv[i], dumpscript_opt, dumpscript_len) == 0)
>> Please use strcmp, and drop dumpscript_len.
>
> okay.  But don't come crying to me if somebody populates your argv[] with 
> non-null-terminated strings.

How would that be possible?  ISO C guarantees them to be strings, i.e.,
null-terminated runs of characters.

>> Probably for the cross-compile + simulator case we'd need to allow for
>> some override.  Not sure if we want to factor out the path translation
>> (also not sure if we couldn't just use $fix_srcfile_path for this, and
>> not distinguish between cygwin and mingw at all, but that would be a
>> more far-reaching change).
>
> A halfway step:
>
> if test -n "$TARGETSHELL" ; then
>   # no path translation at all
>   lt_newargv1="$TARGETSHELL"
> else
[...]
>   esac
> fi
> << now use $lt_newargv1 unconditionally >>

Sounds viable.  (picky note: on the right hand side of a shell
assignment, there is no need for double quotes, as word splitting is
disabled there.)

>> [...]
>>> +  {
>>> + char* p = newargz[1];
>>> + while(*p!='\0') {
>>> +   if (*p == '\\') {
>> strchr?
>>> + *p = '/';
>>> +   }
>>> +   p++;
>>> + }
>>> +  }
>
> Thought about it.  But (a) I'd still need the while loop, because I need to 
> replace all '\\' chars, and (b) what else does strchr DO but iterate thru 
> the string?

Iterate faster.

[...]
> may be a few lines longer, but avoids an extra function call...

The compiler may be smart enough to inline the function call.  Of course
it may be smart enough to detect that you're emulating strchr, and
insert its faster version there.  But anyway Let's not try to be clever
here by doing micro-optimization which potentially outsmarts the
compiler/C library.  I think using strchr is clearer.

>>> +  if ( (shwrapperFILE = fopen (newargz[1], "wb")) == 0 )
>> Why binary?
>
> On cygwin, with latest bash, you have to jump thru hoops (set -igncr, use 
> text mounts, etc) to execute scripts that have \r in them, whereas '\n' 
> without '\r' will always work -- even on msys, even on cygwin 'text 
> mounts'.  So, "wt" is *definitely* out.  That leaves "w" which is a very 
> tempting target for someone to "optimize" into "wt" (scripts are text, 
> right?).  So it was either "wb" which always works, or
>
>/* note: do NOT use "wt" here! -- defer to underlying
> * mount type on cygwin
> */
>if ( (shwrapperFILE = fopen (newargz[1], "w")) == 0 )

OK, thanks for the explanation.


>>>for (i=0; i>>{
>>> -DEBUG("(main) newargz[%d]   : %s\n",i,newargz[i]);
>>> +LTWRAPPER_DEBUGPRINT

Re: [cygwin] cwrapper emits wrapper script

[Charles Wilson]

Ralf Wildenhues wrote:

* Charles Wilson wrote on Sat, Apr 21, 2007 at 03:03:02AM CEST:

When the wrapper foo.exe is launched, it generates a new wrapper script
   .libs/foo_ltshwrapper


Hmm, I'm wondering whether we should keep prefixing within .libs.  Maybe
  .libs/ltsh-foo
?  WDYT?


Meh, I don't care.  Which would you prefer:

$ ls tests/mdemo/.libs
cygfoo2-0.dll* libmlib.expmdemo.exeS.o
cygfoo2-0.dll.def  libmlib.la@mdemo_ltshwrapper*
cygmlib-0.dll* libmlib.laimdemo_ltshwrapperTMP*
cygmlib-0.dll.def  libmlibS.c mdemo_static.exe*
cygsub-0.dll*  libmlibS.o mdemo_static.exe.def
foo1.dll*  libsub.dll.a   mdemo_static.exe.exp
foo1.dll.a libsub.la@ mdemo_static.exe.nm
foo1.la@   libsub.lai mdemo_static.exe.nmS
foo1.lai   lt-mdemo.c mdemo_static.exeS.c
foo1.o lt-mdemo_static.c  mdemo_static.exeS.o
foo2.o mdemo.exe* mdemo_static_ltshwrapper*
libfoo2.dll.a  mdemo.exe.def  mdemo_static_ltshwrapperTMP*
libfoo2.expmdemo.exe.exp  mlib.o
libfoo2.la@mdemo.exe.nm   sub.o
libfoo2.laimdemo.exe.nmS
libmlib.dll.a  mdemo.exeS.c

(the above is after a run of mdemo-shared.conf, so even mdemo_static.exe 
is built shared)


Or

$ ls tests/mdemo/.libs
cygfoo2-0.dll* libmlib.expmdemo.exe.exp
cygfoo2-0.dll.def  libmlib.la@mdemo.exe.nm
cygmlib-0.dll* libmlib.laimdemo.exe.nmS
cygmlib-0.dll.def  libmlibS.c mdemo.exeS.c
cygsub-0.dll*  libmlibS.o mdemo.exeS.o
foo1.dll*  libsub.dll.a   mdemo_static.exe*
foo1.dll.a libsub.la@ mdemo_static.exe.def
foo1.la@   libsub.lai mdemo_static.exe.exp
foo1.lai   lt-mdemo.c mdemo_static.exe.nm
foo1.o lt-mdemo_static.c  mdemo_static.exe.nmS
foo2.o ltshTMP-mdemo* mdemo_static.exeS.c
libfoo2.dll.a  ltshTMP-mdemo_static*  mdemo_static.exeS.o
libfoo2.expltsh-mdemo*mlib.o
libfoo2.la@ltsh-mdemo_static* sub.o
libfoo2.laimdemo.exe*
libmlib.dll.a  mdemo.exe.def


The "interesting" option name is to guard against valid program flags,
right? 


Yes.


What do you think about --lt-dump-script?  It would not fit in
with libtool's other flags, though.


But this isn't libtool, per se.  It's a specific wrapper executable. 
The "special" option could be %%%LIBTOOL%%%-dump:::script++ for all the 
difference it makes.  We could standardize (hah!) on '--lt-' for this 
sort of thing if you like.



 Or maybe an environment variable
rather than a flag?  (I'm simply unsure myself, gathering opinions, not
telling you to change your code here.)


Oh, I really don't like having a envvar affect the wrapper that way: 
"okay, see, if LTWRAPPER_NOT_WRAPPING_RIGHT_NOW is set in the 
environment, then running the wrapper executable will cause it to dump a 
wrapper script to stdout, and not run the target at all."  Ick -- just 
wait until I set that envvar manually while debugging something, and 
then forget to unset it later...at least with a cmd-line option, I'm 
actively and explicitly putting the executable into the dumpscript mode 
with each invocation.


This patch ALSO fixes the wrapper executable on mingw, by 
DOS-izing "/bin/sh" when emitting those lines of the executable 
wrapper's source code.


Thanks, that should fix
.
Please note though that translating a path with MSYS can be done like
this (when $build = $host):
cmd //c echo "$srcfile"


Hmm. I didn't know about that. That's much simpler.


but in the cross-compile case, we need to do more work, see this report



Right. I'm not sure what the best approach is.


(note I'm not asking you to do this work here; actually, I'd like to ask
you not to fix even more different things with one patch.  Merely noting
it in case you're interested.)


Ok, but it my defense: NOT fixing the mingw case (e.g. leaving the 
wrapper.exe broken on mingw) + eliminate the wrapper script from '.' == 
break EVERYTHING on mingw.  So, I kinda HAD to address this: and two 
patches that touch exactly the same region of code is rather silly.



 37: compiling softlinked libltdl  FAILED (nonrecursive.at:90)
 38: compiling copied libltdl  FAILED (nonrecursive.at:114)
 39: installable libltdl   FAILED (nonrecursive.at:140)
 40: compiling softlinked libltdl  FAILED (recursive.at:67)
 41: compiling copied libltdl  FAILED (recursive.at:87)
 42: installable libltdl   FAILED (recursive.at:109)


Ah, ok.  Without your patch, I don't get these, but I have 2.61 and 1.10
installed in my MSYS/MinGW, which would explain this.  I also don't
think they have to do with your patch, but will check.


If I bootstrap the patched source on l

Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used

[Bob Friesenhahn]

On Mon, 23 Apr 2007, Ralf Wildenhues wrote:


Both of those two tests work with Debian's current libtool, but break
with your patch.  Note that they also break if -static is used for all
libraries (add LDFLAGS=-static to TESTSUITEFLAGS to try out), rather
than only to the final ones.

Libtool developers: ok to apply the patch, which serves to document
behavior that works and should continue to do so?


Yes, of course!

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: [cygwin] cwrapper emits wrapper script

[Ralf Wildenhues]

Hello Charles,

Thanks for the patch again.  First review:

* Charles Wilson wrote on Sat, Apr 21, 2007 at 03:03:02AM CEST:
> This patch depends on this one: 
> http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00048.html

(unfortunately, due to idiocy on my part, that patch will have to go
through another iteration.  Review to come up in 1-2 days, hopefully.)

> With this patch, after a successful build the following files are created:
>foo.exe   -- the wrapper executable. It does NOT launch the
> wrapper script 'foo' in thisdir (.)
>foo   -- a wrapper script. It could be used to launch the
> target executable, but isn't normally used for that.
> This wrapper is sourced by func_source() when
> necessary.
>.libs/foo.exe -- the target executable
> 
> When the wrapper foo.exe is launched, it generates a new wrapper script
>.libs/foo_ltshwrapper

Hmm, I'm wondering whether we should keep prefixing within .libs.  Maybe
  .libs/ltsh-foo
?  WDYT?

> At present, the .libs/foo_ltwrappersh is recreated every single time the 
> wrapper executable is run; later, timestamps could be used to avoid 
> this, but that's an optimization.

> Furthermore, the wrapper executable can be invoked with the 
> '-ltdumpscript' option, which will emit the script on *stdout*.

The "interesting" option name is to guard against valid program flags,
right?  What do you think about --lt-dump-script?  It would not fit in
with libtool's other flags, though.  Or maybe an environment variable
rather than a flag?  (I'm simply unsure myself, gathering opinions, not
telling you to change your code here.)

> This patch ALSO fixes the wrapper executable on mingw, by 
> DOS-izing "/bin/sh" when emitting those lines of the executable 
> wrapper's source code.

Thanks, that should fix
.
Please note though that translating a path with MSYS can be done like
this (when $build = $host):
cmd //c echo "$srcfile"

but in the cross-compile case, we need to do more work, see this report

(note I'm not asking you to do this work here; actually, I'd like to ask
you not to fix even more different things with one patch.  Merely noting
it in case you're interested.)

>  37: compiling softlinked libltdl  FAILED (nonrecursive.at:90)
>  38: compiling copied libltdl  FAILED (nonrecursive.at:114)
>  39: installable libltdl   FAILED (nonrecursive.at:140)
>  40: compiling softlinked libltdl  FAILED (recursive.at:67)
>  41: compiling copied libltdl  FAILED (recursive.at:87)
>  42: installable libltdl   FAILED (recursive.at:109)

Ah, ok.  Without your patch, I don't get these, but I have 2.61 and 1.10
installed in my MSYS/MinGW, which would explain this.  I also don't
think they have to do with your patch, but will check.

> Failed test was: tests/mdemo-dryrun.test -- false alarm:
> 
> $ diff before after
> 66c66
> < drwxr-xr-x2 cwilson  Administ0 Apr 20  2007 bin
> ---
> > drwxr-xr-x2 cwilson  Administ0 Apr 20 20:29 bin
> 
> Probably need another 'sleep 1' somewhere, but that's outside the scope 
> of this patch.

Hmm, maybe one after the `rm -f "$prefix/bin/..."' and one after the
`$MAKE uninstall' line?

> --- libltdl/config/ltmain.m4sh2007-04-19 19:54:53.5 -0400
> +++ libltdl/config/ltmain.m4sh2007-04-20 03:20:46.28125 -0400
> @@ -2301,6 +2301,20 @@
>  file=\`ls -ld \"\$thisdir/\$file\" | ${SED} -n 's/.*-> //p'\`
>done
>  
> +  # cygwin/mingw cwrapper will rewrite this line:
> +  WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no
> +  if test \"\$WRAPPER_SCRIPT_BELONGS_IN_OBJDIR\" = \"yes\"; then

(Not sure about this WRAPPER_SCRIPT_BELONGS_IN_OBJDIR thing yet.)

> +# special case for '.'
[...]

> @@ -2482,12 +2497,11 @@
>if (stale) { free ((void *) stale); stale = 0; } \
>  } while (0)
>  
> -/* -DDEBUG is fairly common in CFLAGS.  */
> -#undef DEBUG
> +#undef LTWRAPPER_DEBUGPRINTF
>  #if defined DEBUGWRAPPER
> -# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
> +# define LTWRAPPER_DEBUGPRINTF(format, ...) fprintf(stderr, format, 
> __VA_ARGS__)
>  #else
> -# define DEBUG(format, ...)
> +# define LTWRAPPER_DEBUGPRINTF(format, ...)

What's the reason for this change?

> @@ -2496,41 +2510,156 @@
>  char * xstrdup (const char *string);
>  const char * base_name (const char *name);
>  char * find_executable(const char *wrapper);
> +char * chase_symlinks(const char *pathspec);
> +intmake_executable(const char *path);
>  intcheck_executable(const char *path);
>  char * strendzap(char *str, const char *pat);
>  void lt_fatal (const char *message, ...);
>  
> +static const char* script_text = 
> +EOF
> +
> + func_emit_libtool_wrapper_script |\
> + $SED -e 's/\([\\"]\)/\\\1/g' |\
> + $SED 

Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used

[Kurt Roeckx]

On Mon, Apr 23, 2007 at 07:31:38PM +0200, Ralf Wildenhues wrote:
> Hello Kurt, all,
> 
> Thanks for the patch.
> 
> * Kurt Roeckx wrote on Sun, Apr 22, 2007 at 01:22:30AM CEST:
> > 
> > So would the attached patch be acceptable for now?  I'm thinking about
> > adding that to the Debian patch.
> 
> Hmm.  It breaks when -static is used.
> 
> Here's how I tested your patch, as a new test against the testsuite of
> CVS HEAD (apologies, but I rather prefer writing new tests for HEAD;
> the patch contains two tests; the first one belongs to this bug).
> If you're inclined, here's how you can use HEAD's new testsuite with
> an 1.5.x libtool:  get CVS HEAD, bootstrap and compile it.  Then run
> 
>   make check-local TESTSUITEFLAGS="-v -d -x -k indirect \
>LIBTOOL=/path/to/the/1.5.x/libtool"

This is a great trick, thanks!

> Both of those two tests work with Debian's current libtool, but break
> with your patch.  Note that they also break if -static is used for all
> libraries (add LDFLAGS=-static to TESTSUITEFLAGS to try out), rather
> than only to the final ones.

Right, so the problem is with static libraries.  And the solution I had
in mind was that it needs to look at the .la files recursivly.  It
doesn't seem to be doing this.


Kurt

Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used

[Ralf Wildenhues]

Hello Kurt, all,

Thanks for the patch.

* Kurt Roeckx wrote on Sun, Apr 22, 2007 at 01:22:30AM CEST:
> 
> So would the attached patch be acceptable for now?  I'm thinking about
> adding that to the Debian patch.

Hmm.  It breaks when -static is used.

Here's how I tested your patch, as a new test against the testsuite of
CVS HEAD (apologies, but I rather prefer writing new tests for HEAD;
the patch contains two tests; the first one belongs to this bug).
If you're inclined, here's how you can use HEAD's new testsuite with
an 1.5.x libtool:  get CVS HEAD, bootstrap and compile it.  Then run

  make check-local TESTSUITEFLAGS="-v -d -x -k indirect \
   LIBTOOL=/path/to/the/1.5.x/libtool"

Both of those two tests work with Debian's current libtool, but break
with your patch.  Note that they also break if -static is used for all
libraries (add LDFLAGS=-static to TESTSUITEFLAGS to try out), rather
than only to the final ones.

Libtool developers: ok to apply the patch, which serves to document
behavior that works and should continue to do so?

Cheers,
Ralf

* tests/indirect_deps.at: New file, with tests to ensure
`link_all_deplibs=no' does not break functionality.
* Makefile.am: Adjust.

Index: Makefile.am
===
RCS file: /cvsroot/libtool/libtool/Makefile.am,v
retrieving revision 1.216
diff -u -r1.216 Makefile.am
--- Makefile.am 29 Mar 2007 18:09:37 -  1.216
+++ Makefile.am 23 Apr 2007 17:16:59 -
@@ -439,6 +441,7 @@
  tests/export.at \
  tests/search-path.at \
  tests/destdir.at \
+ tests/indirect_deps.at \
  tests/old-m4-iface.at \
  tests/am-subdir.at \
  tests/lt_dlexit.at \
--- /dev/null   2007-04-15 17:46:43.220064750 +0200
+++ tests/indirect_deps.at  2007-04-23 19:20:14.0 +0200
@@ -0,0 +1,117 @@
+# indirect_deps.at -- support for link_all_deplibs=no   -*- Autotest -*-
+
+#   Copyright (C) 2007 Free Software Foundation, Inc.
+#   Written by Ralf Wildenhues, 2007.
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_SETUP([indirect convenience])
+AT_KEYWORDS([libtool])
+
+AT_DATA([a.c], [[
+#include 
+int a () { return 0; }
+double ad (double x) { return sin (x); }
+]])
+AT_DATA([b.c], [[
+extern int a ();
+extern double ad (double);
+int b () { return a () + (int) ad (0.0); }
+]])
+AT_DATA([c.c], [[
+extern int b ();
+int c () { return b (); }
+]])
+AT_DATA([m.c], [[
+extern int c ();
+int main () { return c (); }
+]])
+
+LDFLAGS="$LDFLAGS -no-undefined"
+for file in a.c b.c c.c; do
+  $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c $file
+done
+$CC $CPPFLAGS $CFLAGS -c m.c
+
+# liba is an indirect dependency of libd and of libconv.
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o liba.la a.lo -rpath 
/nowhere -lm
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libb.la b.lo liba.la 
-rpath /nowhere
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libconv.la c.lo libb.la
+$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o libd.la libconv.la 
-rpath /nowhere
+
+for st in '' -static; do
+  AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS $st -o m1 
m.$OBJEXT libd.la],
+  [], [ignore], [ignore])
+  AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS $st -o m2 
m.$OBJEXT libconv.la],
+  [], [ignore], [ignore])
+  LT_AT_EXEC_CHECK([./m1])
+  LT_AT_EXEC_CHECK([./m2])
+done
+
+AT_CLEANUP
+
+
+AT_SETUP([indirect uninstalled])
+AT_KEYWORDS([libtool])
+
+AT_DATA([a.c], [[
+int a () { return 0; }
+]])
+AT_DATA([b.c], [[
+extern int a ();
+int b () { return a (); }
+]])
+AT_DATA([c.c], [[
+extern int b ();
+int c () { return b (); }
+]])
+
+AT_DATA([m1.c], [[
+extern int b ();
+int main () { return b (); }
+]])
+AT_DATA([m2.c], [[
+extern int c ();
+int main () { return c (); }
+]])
+
+mkdir a b c
+LDFLAGS="$LDFLAGS -no-undefined"
+for file in a.c b.c c.c; do
+  $LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c $file
+done
+for file in m1.c m2.c; do
+  $CC $CPPFLAGS $CFLAGS -c $file
+done
+
+for st in ''

Re: HEAD: fix the inherited_linker_flags regression

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Apr 12, 2007 at 12:09:07AM CEST:
> Prior to this patch, inherite_linker_flags from all dependent libraries
> would accumulate [...]

No comments in 11 days.  I've applied this patch now.

Cheers,
Ralf

> 2007-04-11  Ralf Wildenhues  <[EMAIL PROTECTED]>
> 
>   * libltdl/config/ltmain.m4sh (func_mode_link): Fix accumulation
>   of `inherited_linker_flags' entries from multiple deplibs, by
>   adding $new_inherited_linker_flags only once, only in link pass.
>   * tests/inherited_flags: Amend test to expose this.
>   * NEWS: Adjust: kill one regression, but add note about the
>   feature new in 1.9b.
>   Report by Jeff Squyres and others.

Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source

[Ralf Wildenhues]

Hello Charles,

* Charles Wilson wrote on Thu, Apr 19, 2007 at 11:40:58PM CEST:
>
> 2007-04-19  Charles Wilson  <[EMAIL PROTECTED]>
>
>   * libltdl/config/ltmain.m4sh (func_mode_link): move wrapper
>   script generation from here...
>   (func_emit_libtool_wrapper_script): to this new function, and
>   write to stdout
>   (func_mode_link): move cwrapper source code generation from
>   here...
>   (func_emit_libtool_cwrapperexe_source): to this new function,
>   and write to stdout
>   (func_mode_link): call the two new functions and redirect
>   output to appropriate file.

Thanks.  I've applied this patch.

Cheers,
Ralf

ltmain not rebuilt

[Ralf Wildenhues]

Just to let everyone know again: current Makefile.am of CVS HEAD does
NOT ensure that the libtool script is rebuilt if you change ltmain.m4sh
and run `make'.  The 2007-03-26 change broke this, and any testing of
patches to ltmain.m4sh will be affected.

I've posted a partial workaround here:

which isn't portable enough though.

Cheers,
Ralf