Re: [cygwin] cwrapper emits wrapper script
* Charles Wilson wrote on Thu, Apr 26, 2007 at 12:41:08AM CEST: > > The only problem I see is if libtool-HEAD-after-2.0 (say, nearing the > /next/ major release) begins requiring ac-2.61/am-1.10 (or even > newer). You'll have my vote against that happening too soon. > I suspect they will make more of an effort to keep up with current > autotools, plus I think any future ac/am updates will be much less, err, > issue-prone than the ac-2.13/ac-2.5x transition was. Let's also reverse that statement: the more GCC keeps up to date with autotools, the less there is a chance that they will regress wrt. the functionality that GCC needs. Of course if people can > On Wed, 25 Apr 2007 23:01:10 +0200, "Ralf Wildenhues" > > Primary aim is to release Libtool 2. Effectively you are suggesting > > that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW > > breakage of cwrapper be considered release blockers. > > The latter two, yes: see below. The first one: no. Only, if you ARE > going to accept it before 2.0, then I'd prefer to get that done before > the upcoming gcc import, rather than miss it by a few days. If you're > NOT going to accept it pre-2.0, or if it takes a month to stabilize and > we miss the gcc "deadline" by _weeks_, then no problem. We can try, but running toward a deadline that's not known in advance can be challenging. ;-) > It was you who said in response, last week: > http://cygwin.com/ml/cygwin/2007-04/msg00549.html > "... I'd prefer to see such a patch before deciding when it's good to > put it in." Yes, and I stand by that now. Because I understand that these bugs are important to fix. Count all my other inconsistencies wrt. what I said months ago as me being wrong about when we'd have version 2 finished. Let's try to be as pragmatic as possible. Hope that works out. Cheers, Ralf
Re: mdemo ltdl failure
Charles Wilson wrote:
I'll generate and
test an additional patch addressing Bruno's concerns.
Attached. Re-ran *all* of the tests described here:
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00073.html
with identical results.
I did not bump the argz.m4 serial again (I'm not sure what the rules
are: bump on EVERY change, or only on "big" changes?). So, Ralf, please
do that manually if it is necessary.
--
Chuck
2007-04-26 Charles Wilson <[EMAIL PROTECTED]>
* libltdl/libltdl/lt__glibc.h: use !HAVE_WORKING_ARGZ
instead of SYSTEM_ARGZ_IS_BROKEN
* libltdl/m4/argz.m4 (gl_FUNC_ARGZ): ditto. Also, minor
stylistic improvements
Reported by: Bruno Haible <[EMAIL PROTECTED]>
Index: libltdl/libltdl/lt__glibc.h
===
RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__glibc.h,v
retrieving revision 1.9
diff -u -r1.9 lt__glibc.h
--- libltdl/libltdl/lt__glibc.h 25 Apr 2007 21:17:59 - 1.9
+++ libltdl/libltdl/lt__glibc.h 26 Apr 2007 00:33:34 -
@@ -37,7 +37,7 @@
# include
#endif
-#if !defined(HAVE_ARGZ_H) || defined(SYSTEM_ARGZ_IS_BROKEN)
+#if !defined(HAVE_ARGZ_H) || !defined(HAVE_WORKING_ARGZ)
/* Redefine any glibc symbols we reimplement to import the
implementations into our lt__ namespace so we don't ever
clash with the system library if our clients use argz_*
Index: libltdl/m4/argz.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/argz.m4,v
retrieving revision 1.5
diff -u -r1.5 argz.m4
--- libltdl/m4/argz.m4 25 Apr 2007 21:17:59 - 1.5
+++ libltdl/m4/argz.m4 26 Apr 2007 00:33:34 -
@@ -41,34 +41,35 @@
[AC_CACHE_CHECK(
[if argz actually works],
[lt_cv_sys_argz_works],
-[case $host_os in #(
+[[case $host_os in #(
*cygwin*)
lt_cv_sys_argz_works=no
if test "$cross_compiling" != no; then
lt_cv_sys_argz_works="guessing no"
else
+lt_sed_extract_leading_digits='s/^\([0-9\.]*\).*/\1/'
save_IFS=$IFS
IFS=-.
-set x `uname -r | $SED -e 's/^\([[0-9\.]]*\).*/\1/'`
+set x `uname -r | sed -e "$lt_sed_extract_leading_digits"`
IFS=$save_IFS
-lt_os_major=$[]{2-0}
-lt_os_minor=$[]{3-0}
-lt_os_micro=$[]{4-0}
-if test "$lt_os_major" -gt 1 ||
- { test "$lt_os_major" -eq 1 &&
- { test "$lt_os_minor" -gt 5 ||
- { test "$lt_os_minor" -eq 5 &&
- test "$lt_os_micro" -gt 24; }; }; }; then
+lt_os_major=${2-0}
+lt_os_minor=${3-0}
+lt_os_micro=${4-0}
+if test "$lt_os_major" -gt 1 \
+ || { test "$lt_os_major" -eq 1 \
+ && { test "$lt_os_minor" -gt 5 \
+ || { test "$lt_os_minor" -eq 5 \
+ && test "$lt_os_micro" -gt 24; }; }; }; then
lt_cv_sys_argz_works=yes
fi
fi
;; #(
*) lt_cv_sys_argz_works=yes ;;
-esac])
- AS_IF([test $lt_cv_sys_argz_works != yes],
-[AC_DEFINE([SYSTEM_ARGZ_IS_BROKEN], 1,
- [This value is set to 1 to indicate that the system argz
facility does not work])
-ARGZ_H=argz.h
+esac]])
+ AS_IF([test $lt_cv_sys_argz_works = yes],
+[AC_DEFINE([HAVE_WORKING_ARGZ], 1,
+ [This value is set to 1 to indicate that the system argz
facility works])],
+[ARGZ_H=argz.h
AC_LIBOBJ([argz])])])
AC_SUBST([ARGZ_H])
Re: mdemo ltdl failure
On Wed, 25 Apr 2007 23:57:13 +0200, "Bruno Haible" <[EMAIL PROTECTED]> [Lots of good comments...snipped] As I was the originator of this change (though not its final form), and because Ralf has already committed it to libtool cvs, I'll generate and test an additional patch addressing Bruno's concerns. Then Ralf can propagate the update over to the gnulib folks. > Also, I don't see where in the C code this macro SYSTEM_ARGZ_IS_BROKEN is > being tested. It is being used on the libtool side in libltdl/libltdl/lt__glibc.h: -#if !defined(HAVE_ARGZ_H) +#if !defined(HAVE_ARGZ_H) || defined(SYSTEM_ARGZ_IS_BROKEN) /* Redefine any glibc symbols we reimplement to import the implementations into our lt__ namespace so we don't ever clash with the system library if our clients use argz_* -- Chuck
Re: [cygwin] cwrapper emits wrapper script
On Wed, 25 Apr 2007 23:01:10 +0200, "Ralf Wildenhues" > FWIW, this isn't going to change a lot for me. If I have doubts that > changes are free of regressions, then there is work to be done. agreed. > It's > not helpful if GCC developers have to sort out those regressions. > Conversely, if GCC retains the policy of updating its Libtool files at > most once every decade, then we can't help them, no matter what bug > we're talking about. Right. The problem was that they had modified their local version of libtool-1.4.x, and were therefore nervous about upgrading and losing those "fixes". Plus, they had to update autoconf from 2.13 and automake from 1.[4p5|7|8,depending] throughout, first -- and that took a while. A looog while. However, similar problems should be avoided in the future, because from what I understand, the new rules are: either use an official, unpatched, released version of external tools (like libtool), or use an unpatched version taken directly from the external development tree. The only problem I see is if libtool-HEAD-after-2.0 (say, nearing the /next/ major release) begins requiring ac-2.61/am-1.10 (or even newer). Then gcc would be stuck with their unpatched snapshot of libtool-HEAD from before that new libtool requirement, until they updated ac/am. I suspect they will make more of an effort to keep up with current autotools, plus I think any future ac/am updates will be much less, err, issue-prone than the ac-2.13/ac-2.5x transition was. > Primary aim is to release Libtool 2. Effectively you are suggesting > that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW > breakage of cwrapper be considered release blockers. The latter two, yes: see below. The first one: no. Only, if you ARE going to accept it before 2.0, then I'd prefer to get that done before the upcoming gcc import, rather than miss it by a few days. If you're NOT going to accept it pre-2.0, or if it takes a month to stabilize and we miss the gcc "deadline" by _weeks_, then no problem. > Which I personally don't have a problem with, especially if you're the > one doing all the hard work and effectively end up doing the maintenance > as well. ;-) But I think that should be noted. And the next time you > cry about the release process being ever slower, I'll remind you of this > point. ;-) I call shenanigans. The argz stuff notwithstanding, the very idea of fixing the "transparent_exe" issue &etc was rejected by me a year ago as being too destabilizing for 2.0(.0), which was due Real Soon Then. http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html "Sadly, it's too late for any such major change to get into libtool-2.0[ed: 2.0.0 initial release] because libtool is effectively in code-slush right now. But, if *somebody* implements this fix I'll put it in cygwin's dist of libtool-2.0 and push for it to go into libtool-2.0.x.[ed: x > 0]" It was rejected AGAIN by me two weeks ago as being too destabilizing for 2.0: http://cygwin.com/ml/cygwin/2007-04/msg00543.html "Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so the desired fixes will have to wait until after 2.0." It was you who said in response, last week: http://cygwin.com/ml/cygwin/2007-04/msg00549.html "... I'd prefer to see such a patch before deciding when it's good to put it in." So, I began feeding those patches. I was surprised when you accepted in principle -- and then actually committed -- the first "use functions to emit wrapper code" patch without even seeing the others. Despite my surprise, I continued feeding the others, because if one of the three patches was actually accepted, code slush or no, then I really didn't want the official libtool-2.0(.0) to have only a partly finished implementation (only one of the three phases). Granted, I have implemented all three phases with only backwards-dependence: HEAD+phase1-only works. HEAD+phase1-and-phase2-only works. HEAD+all-three-phases works. There's no functional breakage by taking only phase1, or only phase1 and phase2. But it strikes me as odd to do so, else why take phase 1 at all? Note that my original email, from last year, actually specified three separate phases, and strongly implied that they would each be implemented separately (e.g. three separate patches) -- although my implementation, and theory-of-operation, of #2 was a bit different than I originally proposed, causing #3 to differ as well. But that's beside the point. The argz stuff: actually fixes a _bug_ that was exposed by failing mdemo tests on cygwin, which began failing ~six months ago (I no longer remember exactly when, nor what change in either libtool or cygwin was the proximate cause; perhaps cygwin first began exporting the newlib argz symbols?). The mingw change fixes a hitherto unnoticed bug in that the mingw wrapper executables _did not work_ -- ever. I suspect the upcoming MSYS-1.0.11 release with its updated coreutils and b
Re: mdemo ltdl failure
Hi Ralf,
A bit of gnitpicking:
Ralf Wildenhues wrote:
> Here's what the gnulib patch looks like.
> + set x `uname -r | $SED -e 's/^\([[0-9\.]]*\).*/\1/'`
$SED is usually not defined in the context of autoconf macros that are
part of gnulib. (I.e. it expands to empty.) Just use 'sed' instead.
Also, literals containing backslashes inside backquote cause trouble.
You normally need to write \\. instead of \. because of the outer
backquotes; only some shells (like bash) allow the use of \. inside backquote.
I recommend to assign this literal to a variable outside backquote. This
lso has the added benefit of documenting the meaning of the literal:
sed_extract_leading_digits='s/^\([[0-9\.]]*\).*/\1/'
set x `uname -r | sed -e "$sed_extract_leading_digits"`
> +[case $host_os in #(
> + *cygwin*)
> +lt_cv_sys_argz_works=no
> +if test "$cross_compiling" != no; then
> + lt_cv_sys_argz_works="guessing no"
> +else
> + save_IFS=$IFS
> + IFS=-.
> + set x `uname -r | $SED -e 's/^\([[0-9\.]]*\).*/\1/'`
> + IFS=$save_IFS
> + lt_os_major=$[]{2-0}
> + lt_os_minor=$[]{3-0}
> + lt_os_micro=$[]{4-0}
This $[] is confusing. The entire shell code would be easier to understand
if you added a quoting level to all of it:
[[case $host_os in #(
*cygwin*)
lt_cv_sys_argz_works=no
if test "$cross_compiling" != no; then
lt_cv_sys_argz_works="guessing no"
else
save_IFS=$IFS
IFS=-.
set x `uname -r | $SED -e 's/^\([0-9\.]*\).*/\1/'`
IFS=$save_IFS
lt_os_major=${2-0}
lt_os_minor=${3-0}
lt_os_micro=${4-0}
...
]]
> + if test "$lt_os_major" -gt 1 ||
> + { test "$lt_os_major" -eq 1 &&
> + { test "$lt_os_minor" -gt 5 ||
> + { test "$lt_os_minor" -eq 5 &&
> + test "$lt_os_micro" -gt 24; }; }; }; then
The GNU standards ask, when breaking lines near an operator. for putting
the operator on the beginning of the second line, not at the end of the
first line.
> +[AC_DEFINE([SYSTEM_ARGZ_IS_BROKEN], 1,
> + [This value is set to 1 to indicate that the system argz
> facility does not work])
Most AC_DEFINEs have a positive sense rather than a negative one: can you
define a HAVE_WORKING_ARGZ in the opposite case, rather than this one?
Also, I don't see where in the C code this macro SYSTEM_ARGZ_IS_BROKEN is
being tested.
Bruno
Re: mdemo ltdl failure
[ http://thread.gmane.org/gmane.comp.gnu.libtool.patches/7314/focus=7498 ]
Thanks Charles for all your work on this. I installed this path into
Libtool HEAD, and pulled the changes over to gnulib. Here's what the
gnulib patch looks like.
Cheers,
Ralf
2007-04-25 Charles Wilson <[EMAIL PROTECTED]>
Ralf Wildenhues <[EMAIL PROTECTED]>
* lib/argz_.h: ensure error_t definition is obtained in same
mechanism system argz.h would have.
* m4/argz.m4 (gl_FUNC_ARGZ): add new test to check if $host's
argz facilities are known bad. Err on the side of caution if
cross-compiling.
Index: lib/argz_.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/argz_.h,v
retrieving revision 1.5
diff -u -r1.5 argz_.h
--- lib/argz_.h 29 Mar 2007 15:02:55 - 1.5
+++ lib/argz_.h 25 Apr 2007 21:16:56 -
@@ -1,6 +1,6 @@
/* lt__argz.h -- internal argz interface for non-glibc systems
- Copyright (C) 2004 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2007 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2004
NOTE: The canonical source of this file is maintained with the
@@ -32,6 +32,8 @@
#define LT__ARGZ_H 1
#include
+#define __need_error_t
+#include
#include
#if defined(LTDL)
Index: m4/argz.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/argz.m4,v
retrieving revision 1.5
diff -u -r1.5 argz.m4
--- m4/argz.m4 29 Mar 2007 15:02:55 - 1.5
+++ m4/argz.m4 25 Apr 2007 21:16:57 -
@@ -1,13 +1,13 @@
# Portability macros for glibc argz.-*- Autoconf -*-
#
-# Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
# Written by Gary V. Vaughan <[EMAIL PROTECTED]>
#
# This file is free software; the Free Software Foundation gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
-# serial 4 argz.m4
+# serial 5 argz.m4
AC_DEFUN([gl_FUNC_ARGZ],
[gl_PREREQ_ARGZ
@@ -27,6 +27,50 @@
ARGZ_H=
AC_CHECK_FUNCS([argz_append argz_create_sep argz_insert argz_next \
argz_stringify], [], [ARGZ_H=argz.h; AC_LIBOBJ([argz])])
+
+dnl if have system argz functions, allow forced use of
+dnl libltdl-supplied implementation (and default to do so
+dnl on "known bad" systems). Could use a runtime check, but
+dnl (a) detecting malloc issues is notoriously unreliable
+dnl (b) only known system that declares argz functions,
+dnl provides them, yet they are broken, is cygwin
+dnl releases prior to 16-Mar-2007 (1.5.24 and earlier)
+dnl So, it's more straightforward simply to special case
+dnl this for known bad systems.
+AS_IF([test -z "$ARGZ_H"],
+[AC_CACHE_CHECK(
+[if argz actually works],
+[lt_cv_sys_argz_works],
+[case $host_os in #(
+*cygwin*)
+ lt_cv_sys_argz_works=no
+ if test "$cross_compiling" != no; then
+lt_cv_sys_argz_works="guessing no"
+ else
+save_IFS=$IFS
+IFS=-.
+set x `uname -r | $SED -e 's/^\([[0-9\.]]*\).*/\1/'`
+IFS=$save_IFS
+lt_os_major=$[]{2-0}
+lt_os_minor=$[]{3-0}
+lt_os_micro=$[]{4-0}
+if test "$lt_os_major" -gt 1 ||
+ { test "$lt_os_major" -eq 1 &&
+ { test "$lt_os_minor" -gt 5 ||
+ { test "$lt_os_minor" -eq 5 &&
+ test "$lt_os_micro" -gt 24; }; }; }; then
+ lt_cv_sys_argz_works=yes
+fi
+ fi
+ ;; #(
+*) lt_cv_sys_argz_works=yes ;;
+esac])
+ AS_IF([test $lt_cv_sys_argz_works != yes],
+[AC_DEFINE([SYSTEM_ARGZ_IS_BROKEN], 1,
+ [This value is set to 1 to indicate that the system argz
facility does not work])
+ARGZ_H=argz.h
+AC_LIBOBJ([argz])])])
+
AC_SUBST([ARGZ_H])
])
Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used
* Eric Blake wrote on Wed, Apr 25, 2007 at 02:08:38AM CEST: > According to Ralf Wildenhues on 4/24/2007 3:05 PM: > > Let's document a useful variant of it then. Is this wording OK? > > * README, README.alpha: Document how to test an arbitrary > > installed libtool script. > > Looks great to me! Go ahead and install these hints. Done, thanks! Cheers, Ralf
Re: [cygwin] cwrapper emits wrapper script
* Charles Wilson wrote on Wed, Apr 25, 2007 at 04:42:38AM CEST: > > FYI, I'm going to focus on the argz patch before returning to this one. Which is fine. > (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) FWIW, this isn't going to change a lot for me. If I have doubts that changes are free of regressions, then there is work to be done. It's not helpful if GCC developers have to sort out those regressions. Conversely, if GCC retains the policy of updating its Libtool files at most once every decade, then we can't help them, no matter what bug we're talking about. Primary aim is to release Libtool 2. Effectively you are suggesting that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW breakage of cwrapper be considered release blockers. Which I personally don't have a problem with, especially if you're the one doing all the hard work and effectively end up doing the maintenance as well. ;-) But I think that should be noted. And the next time you cry about the release process being ever slower, I'll remind you of this point. ;-) Cheers, Ralf
Re: preparing for 1.5.24
Hi Charles,
* Charles Wilson wrote on Wed, Apr 25, 2007 at 05:38:49AM CEST:
> Ralf Wildenhues wrote:
>
>> Thanks also for the documentation suggestion. Slightly rewritten
>> suggestion to come up.
>
> Ping? [antecedent reposted below]
Sigh. I had hoped to have enough time to work on this. Alas, I better
just post my thoughts. Apologies for being the eye of the needle here
(can you use the phrase this way in English?).
First, I think this is a bit ad hoc here: the dllexport/dllimport issue,
or more generally, w32-specific issues (although as I understand it's
not /strictly/ w32-specific), don't start with using libltdl. As such,
I think they deserves its own chapter in the manual, and then the
libltdl handling can refer to it, in shortened form. Ideally, all the
gory details of how you can have several deplibs, some static some
shared, and currently need to define a macro for each based on that (but
maybe libtool can help there in the future to automatize that?).
AC_LIBTOOL_WIN32_DLL could refer to this section then.
I think some of this stuff has been discussed at length on the libtool
lists; I assume you were one of the people involved.
Even cooler would be to take into account the differences for when we
add support for MSVC, wgcc, ...
> Around line 3546 [probably 4476, now] in libtool.texi, something like:
>
> --%<
> @emph{Win32 specific}
FWIW, I don't like this way of putting keywords much. It should be a
heading, or part of the surrounding sentence.
> When building a DLL on windows (MinGW,Cygwin) that
Let's not speak of a library as a DLL, except where we explain what a
DLL is, and except the strictly w32-specific parts of the manual. We
should strive to use coherent names for things, here: shared library.
Just like you use "convenience archive" within the same sentence.
> 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/}.
Let's rather not refer to an external source here: they could change,
the link is more than two links away from what the user really needs to
see when doing this, and zlib isn't GNU software (it's free, so there's
no real issue here).
Rather, a small, self-contained example would be great. Ideally, that
example would be identical to a test in the new testsuite, so that we're
kept honest in that it actually works as expected.
> @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*)
This doesn't account for specifity to GNU binutils ld. $with_gnu_ld
should help here, bugs in its setting notwithstanding.
> RESTORE_AUTOEXPORT="-Xlinker --export-all-symbols"
[...]
Cheers, and thanks for all your work,
Ralf
