Ralf Wildenhues wrote:
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. <g>

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

I'll take a look. During my most recent testsuite run on mingw, tho, I didn't see the problem (which is typical of this particular mingwism).

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

Been there, done that, got the T-shirt.

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

You are correct.

keeping this change is fine.

Thanks.  This is weird, tho.  On the 1.5 branch (25 Nov 2005):
  cvs diff -r 1.334.2.104 -r 1.334.2.105 ltmain.in

+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG
+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+# define DEBUG(format, ...)

was committed all at once.  On the trunk (6 Nov 2003) at
   cvs diff -r 1.352 -r 1.353 ltmain.in
only the following hunk was committed

+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+# define DEBUG(format, ...)

and the brown-paper-bag fix came along a year later (1 Nov 2004) after the file had been moved from <top>/ltmain.in to <top>/config/ltmain.m4sh (but before it was moved AGAIN to <top>/libltdl/config/ltmain.m4sh):

    cvs diff -r 1.17 -r 1.18 ltmain.m4sh

+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG

And it was a year after THAT (25 Nov 2005), that the now-improved version was committed to the 1.5 branch. I had forgotten that the exectuable wrappers went into HEAD first.

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.


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.

You must have missed my invisible <sarcasm> tag.

if test -n "$TARGETSHELL" ; then
  # no path translation at all
<< 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.)


I think using strchr is clearer.


+  if ( (shwrapperFILE = fopen (newargz[1], "wb")) == 0 )
Why binary?
[snip explanation]
OK, thanks for the explanation.

What's that extra ; for BTW?
If !DEBUGWRAPPER, then LTWRAPPER_DEBUGPRINTF() goes away completely, and gcc complains about the empty body in the for loop.

D'oh.  Thanks.

See side thread.

Nope, can't do that here. IS_DIR_SEPARATOR(c) checks whether c is '\\' OR '/'; trying to use strrchr in that situation is more confusing than it is worth.

Ah, ok.  Sorry.

FYI, I'm going to focus on the argz patch before returning to this one. (I am pushing a bit, because if possible and acceptable to [Ralf|Gary|others], I want to get both the argz stuff and as much of the "eliminate .exe/shell wrapper in same directory confusion" work as I can, into libtool-HEAD before Steve Ellcey commits the updated "libtool ToT" files to gcc svn...which if I'm reading the tea leaves correctly is Real Soon Now)


Reply via email to