Re: [cygwin] cwrapper emits wrapper script

2007-04-24 Thread Charles Wilson

Ralf Wildenhues wrote:

* Ralf Wildenhues wrote on Tue, Apr 24, 2007 at 08:53:46AM CEST:

* Charles Wilson wrote on Tue, Apr 24, 2007 at 04:34:41AM CEST:

Ralf Wildenhues wrote:

   for (i=0; iargc+1; i++)
   {
-DEBUG((main) newargz[%d]   : %s\n,i,newargz[i]);
+LTWRAPPER_DEBUGPRINTF((main) newargz[%d]   : %s\n,i,newargz[i]);
 ;

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.


No, wrong.  If LTWRAPPER_DEBUGPRINTF goes away, then the semicolon at
the end of the LTWRAPPER_DEBUGPRINTF line remains.  I don't see how
there can be a warning with one but no warning with two semicolons.
FWIW, my GCC 4.0.3 doesn't warn at all (with -O2 -W -Wall).


Hmm.  The original commit that added this DEBUG() stuff was here:
   cvs diff -r 1.352 -r 1.353 ltmain.in
at libtool toplevel.  It shows:

...
+
+  for (i=0; iargc+1; i++)
+  {
+DEBUG((main) newargz[%d]   : %s\n,i,newargz[i]);
+;
+  }
+
 EOF

So this one/two semicolon thing was committed all at once.  [Aside: 
cygwin's gcc at that time was 3.3.3].  I *distinctly* remember having to 
add the second semicolon during my testing before I posted the patch.


Speculation: maybe I originally defined the DEBUG() macro as a 
'semicolon-swallowing' form something like:


+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) \
+do { fprintf(stderr, format, __VA_ARGS__); } while(0)
+#else
+# define DEBUG(format, ...) \
+#   do { ; } while(0)
+#endif

for whatever reason, so I needed the second semicolon. Or, maybe

+#if defined DEBUGWRAPPER
+# define DEBUG(args) printf(args);  not fprintf! own semicolon
+#else
+# define DEBUG(args)
+#endif

and expected semicolon-less usage like
   DEBUG( (format string, some, arguments) )



Then, maybe I later fixed the DEBUG() macro to more-or-less its current 
form:


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

but never removed the now-superfluous second semicolon.  In any case, I 
*know* the second one was necessary at some point, but perhaps only in 
my private development.


You're right, tho: it certainly is not needed now.

--
Chuck





Re: [cygwin] cwrapper emits wrapper script

2007-04-24 Thread Charles Wilson

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.


Sure.


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.


Anyway,
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__)
+#else
+# define DEBUG(format, ...)
+#endif

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__)
+#else
+# define DEBUG(format, ...)
+#endif

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.


Ack.

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
  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.)


Ack.


I think using strchr is clearer.


Okay.


+  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.


strrchr?
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)


--
Chuck




Re: preparing for 1.5.24

2007-04-24 Thread Charles Wilson

Ralf Wildenhues wrote:


Thanks also for the documentation suggestion.  Slightly rewritten
suggestion to come up.


Ping? [antecedent reposted below]

--
Chuck

Around line 3546 [probably 4476, now] in libtool.texi, something like:

--%
@emph{Win32 specific} When building a DLL on windows (MinGW,Cygwin) that 
uses @code{libltdl} as a convenience archive, there are some issues with 
symbol decoration that must be carefully managed.  You must do one of 
the following, within the code and/or build machinery of your library:


@enumerate 1
@item explicitly mark as @code{declspec(dllexport)} all symbols in your 
library that should be exported when building your library's source 
code.  However, these symbols should @emph{not} be marked 
@code{declspec(dllexport)} when building @emph{clients} of your library 
-- instead, the symbols should be marked @code{declspec(dllimport)}. 
This procedure will require careful macro design within your library's 
public header files.  An example of this may be found in @file{zlib.h} 
from the zlib distribution @url{http://www.zlib.net/}.


@item use the (win32-specific) linker option @code{-Xlinker 
--export-all-symbols}.  This will restore the expected auto-export 
behavior of the GNU linker on windows.  However, the 
@code{--export-all-symbols} option is specific to the GNU linker's i386 
PE target -- @code{ld} for other targets will not recognize the option. 
 Therefore, using this option will require careful coding in your 
library's @file{Makefile.am} and @file{configure.ac}.  For example:


configure.ac:
@example
...
case $host_os in
cygwin* | mingw* | pw32*)
  RESTORE_AUTOEXPORT=-Xlinker --export-all-symbols
  ;;
*)
  RESTORE_AUTOEXPORT=
  ;;
esac
AC_SUBST(RESTORE_AUTOEXPORT)
...
@end example

Makefile.am
@example
...
libmylibrary_la_LDFLAGS = -no-undefined $(RESTORE_AUTOEXPORT)
...
@end example

@item Use libtool facilities to mimic @code{--export-all-symbols}. 
Unlike the solution above, this solution has the advantage of requiring 
no platform-specific workarounds.  Simply append 
@code{-export-symbols-regex .*} to the @code{_LDFLAGS} for your library:


Makefile.am
@example
...
libmylibrary_la_LDFLAGS = -no-undefined -export-symbols-regex .*
...
@end example
@end enumerate
--%