Re: [cygwin] cwrapper emits wrapper script
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
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
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
--%
