ltmain not rebuilt
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: http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00032.html which isn't portable enough though. Cheers, Ralf
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source
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
Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used
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: [cygwin] cwrapper emits wrapper script
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
http://lists.gnu.org/archive/html/bug-libtool/2007-03/msg8.html.
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
http://lists.gnu.org/archive/html/bug-libtool/2007-02/msg0.html
(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 -e 's/\(WRAPPER_SCRIPT_BELONGS_IN_OBJDIR\)=.*/\1=yes/' |\
+ $SED -e 's/^//' -e
Re: [cygwin] cwrapper emits wrapper script
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 http://lists.gnu.org/archive/html/bug-libtool/2007-03/msg8.html. 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 http://lists.gnu.org/archive/html/bug-libtool/2007-02/msg0.html 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 linux -- with
