[PATCH 365] Only complain that files are up-to-date with --force.
As a side effect, this also means that when `aclocal' copies the libtool macros into `aclocal.m4' libtoolize complains only about the macro files that are missing or not up-to-date. * libtoolize.m4sh (func_echo_once): New function that prints the contents of a named variable only on the first call. (func_aclocal_update_check): New function that compares serial numbers of libtool macros in aclocal.m4 and only diagnoses the missing files. (func_copy, func_copy_cb, func_copy_some_files, func_serial_update) (func_keyword_update, func_ltmain_update, func_config_update) (func_install_update): Accept a new argument naming a variable containing a header string to print with func_echo_once iff any body text is output by this function. (func_install_pkgmacro_subproject, func_install_pkgmacro_parent) (func_install_pkgltdl_files, func_install_pkgconfig_subproject) (func_install_pkgconfig_parent: Set and pass a suitable header string variable for the above functions. (func_serial_update_check): Don't advise rerunning `libtoolize --force' when aclocal.m4 is not m4_including libtoolize installed macro files. * tests/testsuite.at (_LIBTOOLIZE_TRANSFORM): Transform generic /usr/local/share/aclocal paths to point into the uninstalled libtool macro directory. * tests/libtoolize.at: Update tests that were checking for old behaviour of outputing `file is already up to date' even when --force was not passed. * tests/libtoolize.at: New tests to prevent regressions of these smarter messages. * NEWS: Updated. Reported by Olly Betts [EMAIL PROTECTED] --- Okay to Apply? ChangeLog | 32 NEWS|6 ++ libtoolize.m4sh | 217 +++--- tests/libtoolize.at | 217 ++- tests/testsuite.at |5 +- 5 files changed, 339 insertions(+), 138 deletions(-) diff --git a/ChangeLog b/ChangeLog index 081f8fc..136f2b4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,37 @@ 2008-04-21 Gary V. Vaughan [EMAIL PROTECTED] + Only complain that files are up-to-date with --force. + As a side effect, this also means that when `aclocal' copies the + libtool macros into `aclocal.m4' libtoolize complains only about + the macro files that are missing or not up-to-date. + * libtoolize.m4sh (func_echo_once): New function that prints + the contents of a named variable only on the first call. + (func_aclocal_update_check): New function that compares serial + numbers of libtool macros in aclocal.m4 and only diagnoses the + missing files. + (func_copy, func_copy_cb, func_copy_some_files, func_serial_update) + (func_keyword_update, func_ltmain_update, func_config_update) + (func_install_update): Accept a new argument naming a variable + containing a header string to print with func_echo_once iff any + body text is output by this function. + (func_install_pkgmacro_subproject, func_install_pkgmacro_parent) + (func_install_pkgltdl_files, func_install_pkgconfig_subproject) + (func_install_pkgconfig_parent: Set and pass a suitable + header string variable for the above functions. + (func_serial_update_check): Don't advise rerunning `libtoolize + --force' when aclocal.m4 is not m4_including libtoolize installed + macro files. + * tests/testsuite.at (_LIBTOOLIZE_TRANSFORM): Transform generic + /usr/local/share/aclocal paths to point into the uninstalled + libtool macro directory. + * tests/libtoolize.at: Update tests that were checking for old + behaviour of outputing `file is already up to date' even when + --force was not passed. + * tests/libtoolize.at: New tests to prevent regressions of these + smarter messages. + * NEWS: Updated. + Reported by Olly Betts [EMAIL PROTECTED] + Capture lt~obsolete.m4 serial number correctly in libtoolize. * libltdl/m4/lt~obsolete.m4: Add the filename to the #serial marker so that libtoolize's serial number checks can find it diff --git a/NEWS b/NEWS index a9b3b23..df43da7 100644 --- a/NEWS +++ b/NEWS @@ -10,8 +10,14 @@ New in 2.2.4: 2008-??-??: CVS version 2.2.3a, Libtool team: incomplete struct types rather than void*, which means that nearly all casting is eliminated allowing the compiler to provide more type checking. + - libtoolize no longer reports up-to-date files that it would have +copied, unless --force is passed. - No longer reports that lt~obsolete.m4 needs to be added to aclocal.m4 when it is already there. + - When `aclocal' copied the libtool macros directly into `aclocal.m4' +(i.e. AC_CONFIG_MACRO_DIR is not being used), libtoolize no longer +reports that all macros need to be added to `aclocal.m4', and +diagnoses only the macro files that are missing or not up-to-date. New in 2.2.2: 2008-04-01: CVS version 2.2.1a, Libtool team: diff
[PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
* libtoolize.at (func_check_macros): Always advise use of AC_CONFIG_MACRO_DIR when not able to copy libtool macros into the project tree. * tests/libtoolize.at: Update expected test output. * NEWS: Updated. --- Okay to apply? ChangeLog |7 +++ NEWS|2 ++ libtoolize.m4sh | 17 - tests/libtoolize.at | 15 --- 4 files changed, 29 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index 136f2b4..9f815db 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,12 @@ 2008-04-21 Gary V. Vaughan [EMAIL PROTECTED] + Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate. + * libtoolize.at (func_check_macros): Always advise use of + AC_CONFIG_MACRO_DIR when not able to copy libtool macros into + the project tree. + * tests/libtoolize.at: Update expected test output. + * NEWS: Updated. + Only complain that files are up-to-date with --force. As a side effect, this also means that when `aclocal' copies the libtool macros into `aclocal.m4' libtoolize complains only about diff --git a/NEWS b/NEWS index df43da7..8e675c0 100644 --- a/NEWS +++ b/NEWS @@ -18,6 +18,8 @@ New in 2.2.4: 2008-??-??: CVS version 2.2.3a, Libtool team: (i.e. AC_CONFIG_MACRO_DIR is not being used), libtoolize no longer reports that all macros need to be added to `aclocal.m4', and diagnoses only the macro files that are missing or not up-to-date. + - libtoolize now advises use of AC_CONFIG_MACRO_DIR to keep matching +libtool macros in-tree where appropriate. New in 2.2.2: 2008-04-01: CVS version 2.2.1a, Libtool team: diff --git a/libtoolize.m4sh b/libtoolize.m4sh index f83353e..2a4cb1a 100644 --- a/libtoolize.m4sh +++ b/libtoolize.m4sh @@ -1325,16 +1325,15 @@ func_check_macros () ac_config_macro_dir_advised=false # Suggest modern idioms for storing autoconf macros: -if test -z $ac_macrodir$ltdldir; then - if test -z $macrodir || test x$macrodir = x.; then -func_echo Consider adding \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac and -func_echo rerunning libtoolize, to keep the correct libtool macros in-tree. - elif test -z $ac_macrodir$ltdldir; then -func_echo Consider adding \`AC_CONFIG_MACRO_DIR([$macrodir])' to $configure_ac, -func_echo and rerunning libtoolize and aclocal. - fi +if test -z $macrodir || test x$macrodir = x.; then + func_echo Consider adding \`AC_CONFIG_MACRO_DIR([m4])' to $configure_ac and + func_echo rerunning libtoolize, to keep the correct libtool macros in-tree. +elif test -z $ac_macrodir$ltdldir; then + func_echo Consider adding \`AC_CONFIG_MACRO_DIR([$macrodir])' to $configure_ac, + func_echo and rerunning libtoolize and aclocal. +fi -elif test -z $macrodir; then +if test -n $ac_macrodir$ltdldir test -z $macrodir; then my_ac_config_macro_srcdir=$aclocaldir if $opt_ltdl test $macrodir != $subproject_macrodir; then my_ac_config_macro_srcdir=$subproject_macrodir diff --git a/tests/libtoolize.at b/tests/libtoolize.at index 4f67386..3ed3290 100644 --- a/tests/libtoolize.at +++ b/tests/libtoolize.at @@ -505,6 +505,8 @@ AC_OUTPUT AT_DATA([expout], [[libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'. libtoolize: copying file `build-aux/ltmain.sh' +libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and +libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/local/share/aclocal/libtool.m4' libtoolize: `/usr/local/share/aclocal/ltoptions.m4' @@ -634,6 +636,8 @@ AC_DEFUN([LT_INIT], AT_DATA([expout], [[libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' +libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and +libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/local/share/aclocal/libtool.m4' libtoolize: `/usr/local/share/aclocal/ltversion.m4' @@ -648,8 +652,6 @@ LT_AT_CHECK_LIBTOOLIZE([--copy], 0, expout) ## Upgrading an aclocal maintained aclocal.m4 without AC_CONFIG_MACRO_DIR. ## ## --- ## -rm -f aclocal.m4 - LT_AT_ACLOCAL() ## The following code is adapted (and simplified) from libtoolize.m4sh @@ -711,7 +713,12 @@ $SED -e 's,^#.*serial.*ltoptions.m4$,# serial 9 ltoptions.m4,' \ aclocal.m4 aclocal.m4t mv -f aclocal.m4t aclocal.m4 -LT_AT_CHECK_LIBTOOLIZE([--copy], 0) +AT_DATA([expout], +[[libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and +libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. +]]) + +LT_AT_CHECK_LIBTOOLIZE([--copy], 0,
Re: [PATCH 363] Allow better compile time type checking for lt_dladvise
Hallo Ralf, On 21 Apr 2008, at 01:23, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Apr 21, 2008 at 02:39:37AM CEST: * libltdl/lt__private.h (lt__handle, lt__advise): Typedefs removed in favour of... * libltdl/ltdl.h (lt_dlhandle), libltdl/libltdl/lt_dlloader.h (lt_dladvise): ...changing from void* to forward declarations. * libltdl/loaders/dlopen.c, libltdl/loaders/loadlibrary.c, libltdl/lt_dlloader.c, libltdl/ltdl.c: Remove many redundant type casts. * NEWS: Updated. Suggested by Bob Friesenhahn [EMAIL PROTECTED] Does this work with C and C++ compilers? Yes. Does it change the ABI or API? API, definitely not. ABI, not as far as I understand it. If yes, no, then I like it. Otherwise, as nice as it is, it would be a bit inappropriate for a minor release number, no? I took that as a yes vote and pushed the patch. :) Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: Feature request: setting env vars for binary wrappers
Behdad Esfahbod wrote: On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote: I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. And if you are happy with that, good for you. In GNOME though, we want our users to be able to run uninstalled programs. If this feature is not interesting to you, fine. I don't understand why you are so opposing it. In GNU Smalltalk, ./gst is used if you don't need to load any plugin, while tests/gst is used if you need plugins; tests/gst is created by config.status. Most of the time launching ./gst is enough; and since its startup time is much faster than tests/gst, I didn't feel the need to use the more user-friendly executable as the default. I see how you might consider this a poor choice if you have a lot of executables; OTOH autoconf does the same and has 6-7 executables. Paolo
Re: libtool performance status
On Tue, 22 Apr 2008, Ralf Wildenhues wrote: To put some sort of proof to my claims, here's what I get building GM unoptimized (CFLAGS=-g) on GNU/Linux with Libtool 2.2.2. and current master (all timings best of three): [ stuff removed ] Looks like a small but definite improvement to me. :-) Good! With libtool 2.2.X I am really not noticing all that much overhead for users to complain about. There is not enough time to make a mad dash to the coffee machine, much less make it back in the time spent by libtool. Many of the functions that libtool does are necessary. Even a total dolt could eventually come to realize this. Note that I have not tested on the XO laptop (http://www.laptop.org/) to know what the actual impact is on children using libtool in disadvantaged countries with pedal or solar power. I know that the FSF does support this project since they had an XO laptop in their booth. Also note that there is only 1.05s of unaccounted-for elapsed time, also Probably just a difference in how the OS performs its accounting. Hmm. That may or may not be libtool's fault, though; linking in itself isn't so cheap, I/O-wise. Can you please check whether libtool --tag=CXX --config is identical for each of the builds you timed? It is really not as easy as you presume for me to relibtoolize GraphicsMagick for testing. I don't maintain many different autotools installs and with 70+ builds simultaneously sharing one source tree such changes become tedious and time consuming. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool performance status
* Bob Friesenhahn wrote on Tue, Apr 22, 2008 at 05:18:34PM CEST: On Tue, 22 Apr 2008, Ralf Wildenhues wrote: Can you please check whether libtool --tag=CXX --config is identical for each of the builds you timed? It is really not as easy as you presume for me to relibtoolize GraphicsMagick for testing. I don't maintain many different autotools installs and with 70+ builds simultaneously sharing one source tree such changes become tedious and time consuming. Here's a cheap trick: unless you have extravagant ways of configuring libtool, you can just override LIBTOOL: make clean all LIBTOOL=/my/libtool-2.2.2/libtool make clean all LIBTOOL=/my/libtool-current/libtool The libtool scripts often don't even have to be installed. Cheers, Ralf
Re: Feature request: setting env vars for binary wrappers
Hi Paolo, * Paolo Bonzini wrote on Tue, Apr 22, 2008 at 04:32:23PM CEST: In GNU Smalltalk, ./gst is used if you don't need to load any plugin, while tests/gst is used if you need plugins; tests/gst is created by config.status. Most of the time launching ./gst is enough; and since its startup time is much faster than tests/gst, I didn't feel the need to use the more user-friendly executable as the default. But consider that, if libtool creates a shell wrapper anyway, your tests/gst setup now means it goes through two shell wrappers before launching the real thing. Behdad requests an optimization of this: one shell wrapper is created, by libtool (since it may already create one anyway). I don't see the fact that it may sometimes be unneeded for libtool's purposes (and only created for Behdad because he used the env vars option) as a problem at all. This discussion has dragged along quite a bit now. I will try to remain silent now until I've had time to redo the actual patch. Cheers, Ralf
Re: [PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
Hi Gary, * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 08:51:39AM CEST: * libtoolize.at (func_check_macros): Always advise use of AC_CONFIG_MACRO_DIR when not able to copy libtool macros into the project tree. * tests/libtoolize.at: Update expected test output. * NEWS: Updated. --- Okay to apply? Yes this is OK. Thank you. I'm wondering a bit whether we should recommend putting ACLOCAL_AMFLAGS = -I MACRO-DIR in the toplevel Makefile.am. Cheers, Ralf
Re: Feature request: setting env vars for binary wrappers
On Tue, 2008-04-22 at 16:32 +0200, Paolo Bonzini wrote: Behdad Esfahbod wrote: On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote: I perfectly know that user cannot go in build-dir and just to run secure shell daemon/client. And if you are happy with that, good for you. In GNOME though, we want our users to be able to run uninstalled programs. If this feature is not interesting to you, fine. I don't understand why you are so opposing it. In GNU Smalltalk, ./gst is used if you don't need to load any plugin, while tests/gst is used if you need plugins; tests/gst is created by config.status. Most of the time launching ./gst is enough; and since its startup time is much faster than tests/gst, I didn't feel the need to use the more user-friendly executable as the default. Sure, you have updated for the separate-wrapper option. Now what percentage of your users know the difference between ./gst and tests/gst? How many read the doc explaining the difference? I see how you might consider this a poor choice if you have a lot of executables; OTOH autoconf does the same and has 6-7 executables. We're talking about every application using GNOME technology... I don't understand why something as simple as running uninstalled binaries should become so painful on the application developer. Paolo -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759
Re: Feature request: setting env vars for binary wrappers
In GNU Smalltalk, ./gst is used if you don't need to load any plugin, while tests/gst is used if you need plugins; tests/gst is created by config.status. Most of the time launching ./gst is enough; and since its startup time is much faster than tests/gst, I didn't feel the need to use the more user-friendly executable as the default. But consider that, if libtool creates a shell wrapper anyway, your tests/gst setup now means it goes through two shell wrappers before launching the real thing. Yes, but tests/gst adds a series of -dlopen options, and parsing the .la files is slow enough that in most cases you don't want tests/gst but ./gst. Paolo
Re: [PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
* Ralf Wildenhues wrote on Tue, Apr 22, 2008 at 07:49:25PM CEST: * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 08:51:39AM CEST: * libtoolize.at (func_check_macros): Always advise use of AC_CONFIG_MACRO_DIR when not able to copy libtool macros into the project tree. * tests/libtoolize.at: Update expected test output. * NEWS: Updated. --- Okay to apply? Yes this is OK. Thank you. I'm wondering a bit whether we should recommend putting ACLOCAL_AMFLAGS = -I MACRO-DIR in the toplevel Makefile.am. I'm further wondering whether you may want to output the AC_CONFIG_MACRO_DIR recommendation only in verbose mode. Rationale: people may consciously choose not to do so for some reason, and be annoyed by being told to do otherwise. There have been prior such bug reports, so there are users who care. Cheers, Ralf
Re: AC_LIBLTDL_CONVENIENCE
Hello Andreas, * Andreas Schwab wrote on Tue, Apr 22, 2008 at 10:11:11AM CEST: --- libltdl/m4/ltdl.m4 1 Apr 2008 18:23:20 - 1.46 +++ libltdl/m4/ltdl.m4 16 Apr 2008 08:04:41 - @@ -79,7 +79,7 @@ _$0() # AC_LIBLTDL_CONVENIENCE accepted a directory argument in older libtools, # now we have LT_CONFIG_LTDL_DIR: AU_DEFUN([AC_LIBLTDL_CONVENIENCE], -[_LT_CONFIG_LTDL_DIR([$1]) +[_LT_CONFIG_LTDL_DIR(m4_ifval([$1], [$1], [libltdl])) This looks like to few parens (outside of m4_ifval), although I haven't tested that and _LT_CONFIG_LTDL_DIR may require absence of quoting; also, m4_default should be able to simplify: _LT_CONFIG_LTDL_DIR([m4_default([$1], [libltdl])]) I removed the outer parens because I had some expansion error, but I can't reproduce that now. Thanks for the feedback and the example. I'm applying this patch. Cheers, Ralf 2008-04-22 Andreas Schwab [EMAIL PROTECTED] and Ralf Wildenhues [EMAIL PROTECTED] Fix default argument for AC_LIBLTDL_CONVENIENCE. * libltdl/m4/ltdl.m4 (AC_LIBLTDL_CONVENIENCE): Default argument to libltdl. (AC_LIBLTDL_INSTALLABLE): Likewise. * tests/configure-iface.at (convenience libltdl): New test. diff --git a/libltdl/m4/ltdl.m4 b/libltdl/m4/ltdl.m4 index bdecc9d..f6b1064 100644 --- a/libltdl/m4/ltdl.m4 +++ b/libltdl/m4/ltdl.m4 @@ -79,7 +79,7 @@ _$0() # AC_LIBLTDL_CONVENIENCE accepted a directory argument in older libtools, # now we have LT_CONFIG_LTDL_DIR: AU_DEFUN([AC_LIBLTDL_CONVENIENCE], -[_LT_CONFIG_LTDL_DIR([$1]) +[_LT_CONFIG_LTDL_DIR([m4_default([$1], [libltdl])]) _LTDL_CONVENIENCE]) dnl aclocal-1.4 backwards compatibility: @@ -135,7 +135,7 @@ _$0() # AC_LIBLTDL_INSTALLABLE accepted a directory argument in older libtools, # now we have LT_CONFIG_LTDL_DIR: AU_DEFUN([AC_LIBLTDL_INSTALLABLE], -[_LT_CONFIG_LTDL_DIR([$1]) +[_LT_CONFIG_LTDL_DIR([m4_default([$1], [libltdl])]) _LTDL_INSTALLABLE]) dnl aclocal-1.4 backwards compatibility: diff --git a/tests/configure-iface.at b/tests/configure-iface.at index 3fcb0da..9a311dc 100644 --- a/tests/configure-iface.at +++ b/tests/configure-iface.at @@ -275,5 +275,33 @@ AT_CHECK([$MAKE -q main$EXEEXT || exit 1], [1], [ignore], [ignore]) AT_CLEANUP + +## ## +## Convenience libltdl. ## +## ## + +AT_SETUP([convenience libltdl]) + +AT_DATA([configure.ac], +[[AC_INIT +AC_CONFIG_AUX_DIR([libltdl/config]) +AC_LIBLTDL_CONVENIENCE +AC_LIBTOOL_DLOPEN +AC_PROG_LIBTOOL +AC_CONFIG_FILES(Makefile) +AC_OUTPUT +]]) +AT_DATA([Makefile.in], +[[LIBLTDL = @LIBLTDL@ +print-ltdl: + echo $(LIBLTDL) +]]) + +LT_AT_BOOTSTRAP([--ltdl], [-I libltdl/m4], [ignore], [ignore], [], [], [ignore]) +AT_CHECK([$MAKE print-ltdl], [], [stdout]) +AT_CHECK([grep libltdl/libltdlc.la stdout], [], [ignore]) + +AT_CLEANUP + dnl Be careful not to let the definition leak into other tests m4_popdef([_LT_AT_LTDL_SETUP])
Re: libtool 2.2.2, ccache and -all-static
Hi Richard,
* Richard Purdie wrote on Tue, Apr 22, 2008 at 12:29:50PM CEST:
I've noticed another problem with two packages in poky, prelink and
libvorbis. Both packages have areas where LDFLAGS=-all-static is used.
The problem comes about since Poky sets CC to ccache gcc, then libtool
puts the -static flag between ccache and gcc.
Thanks for the bug report, and especially for providing an example to
reproduce it!
libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT -fsigned-char
-DUSE_MEMORY_H -o decoder_example decoder_example.o ../lib/.libs/libvorbis.a
-lm /usr/lib/libogg.a
Confirmed. Fixed as below, committed, put you in THANKS.
Cheers,
Ralf
2008-04-22 Ralf Wildenhues [EMAIL PROTECTED]
Fix regression over 1.5.26 with ccache $CC -all-static.
* libltdl/config/ltmain.m4sh (func_mode_link): Add
$link_static_flag to compile_command and link_command only
later, instead of right after a possible compiler wrapper.
* tests/static.at (ccache -all-static): New test.
* THANKS: Update.
Report by Richard Purdie.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index ff1e50d..ac334dc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3160,9 +3160,6 @@ func_mode_link ()
fi
if test -n $link_static_flag; then
dlopen_self=$dlopen_self_static
- # See comment for -static flag below, for more details.
- func_append compile_command $link_static_flag
- func_append finalize_command $link_static_flag
fi
prefer_static_libs=yes
;;
@@ -3450,7 +3447,11 @@ func_mode_link ()
case $arg in
-all-static)
- # The effects of -all-static are defined in a previous loop.
+ if test -n $link_static_flag; then
+ # See comment for -static flag below, for more details.
+ func_append compile_command $link_static_flag
+ func_append finalize_command $link_static_flag
+ fi
continue
;;
diff --git a/tests/static.at b/tests/static.at
index 74b1c63..1a51d0d 100644
--- a/tests/static.at
+++ b/tests/static.at
@@ -352,3 +352,26 @@ for withdep in no yes; do
done
AT_CLEANUP
+
+
+AT_SETUP([ccache -all-static])
+
+AT_DATA([ccache],
+[[#! /bin/sh
+# poor man's ccache clone
+case $1 in
+-*) echo bogus argument: $1 2; exit 1 ;;
+esac
+exec $@
+]])
+chmod +x ./ccache
+
+AT_DATA([a.c],
+[[int main(void) { return 0; }
+]])
+
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore])
+AT_CHECK([$LIBTOOL --mode=link --tag=CC ./ccache $CC $CFLAGS $LDFLAGS
-all-static a.$OBJEXT -o a],
+[], [ignore])
+
+AT_CLEANUP
Re: [PATCH 365] Only complain that files are up-to-date with --force.
Hi Gary,
* Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 08:49:54AM CEST:
Okay to Apply?
I'd say yes. I have some nits below; I haven't had the time to check
all the logic changes in detail, but I suppose user feedback will weed
out remaining issues. ;-)
Thank you very much for tackling this!
--- a/libtoolize.m4sh
+++ b/libtoolize.m4sh
@@ -202,7 +202,24 @@ configure_ac=configure.in
}
-# func_copy srcfile destfile
+# func_echo_once msg_var
+# Calls func_echo with the value of MSG_VAR, and then sets MSG_VAR= so
+# that subsequent calls have no effect.
+func_echo_once ()
+{
+$opt_debug
+if test -n $1; then
+ my_msg=`eval echo \\\$$1`
Can this line be simplified to
eval my_msg=\$$1
?
+ if test -n $my_msg; then
+func_echo $my_msg
+eval $1=
Those double quotes are pretty superfluous, as they won't survive the
eval. Not that they are a problem at all. :-)
+ fi
+fi
+}
+
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -73,8 +73,9 @@ AT_KEYWORDS([libtoolize])
# ---
# Fix the expected output of installed libtoolize in presence of --program-*.
m4_define([_LIBTOOLIZE_TRANSFORM],
-[lt_name=`$ECHO $LIBTOOLIZE | sed 's,^.*/,,'` # restore font-lock: ''
-sed s/^libtoolize/$lt_name/ $1 $1.t
+[lt_name=`$ECHO $LIBTOOLIZE | sed s,^.*/,,`
+sed s/^libtoolize/$lt_name/
+s,/usr/local/share/aclocal/,$abs_top_srcdir/libltdl/m4/, $1 $1.t
Maybe better use | as sed s command delimiter in the last line?
Cheers,
Ralf
Re: [PATCH 366] Libtoolize now advises AC_CONFIG_MACRO_DIR use where appropriate.
Hallo Ralf, On 22 Apr 2008, at 15:27, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Tue, Apr 22, 2008 at 07:49:25PM CEST: * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 08:51:39AM CEST: * libtoolize.at (func_check_macros): Always advise use of AC_CONFIG_MACRO_DIR when not able to copy libtool macros into the project tree. * tests/libtoolize.at: Update expected test output. * NEWS: Updated. --- Okay to apply? Yes this is OK. Thank you. Thanks for the review! I'm wondering a bit whether we should recommend putting ACLOCAL_AMFLAGS = -I MACRO-DIR in the toplevel Makefile.am. Agreed. I'll add that before I push. I'm further wondering whether you may want to output the AC_CONFIG_MACRO_DIR recommendation only in verbose mode. Rationale: people may consciously choose not to do so for some reason, and be annoyed by being told to do otherwise. There have been prior such bug reports, so there are users who care. I'd rather wait to see if we get complaints before worrying about that too much... especially if we can convert more people to modern idioms in the mean time. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: [PATCH 365] Only complain that files are up-to-date with --force.
On 22 Apr 2008, at 16:16, Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, Thanks again for the fast review :-) * Gary V. Vaughan wrote on Tue, Apr 22, 2008 at 08:49:54AM CEST: Okay to Apply? I'd say yes. + my_msg=`eval echo \\\$$1` Can this line be simplified to eval my_msg=\$$1 ? Yes indeed. +eval $1= Those double quotes are pretty superfluous, as they won't survive the eval. Not that they are a problem at all. :-) I quite like the fact that the say to the reader: this variable is being set to the empty string, so I'm inclined to leave them. +sed s/^libtoolize/$lt_name/ +s,/usr/local/share/aclocal/,$abs_top_srcdir/libltdl/m4/, $1 $1.t Maybe better use | as sed s command delimiter in the last line? Good call. Thanks. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: libtool 2.2.2, ccache and -all-static
Hallo Ralf,
On 22 Apr 2008, at 15:43, Ralf Wildenhues wrote:
* Richard Purdie wrote on Tue, Apr 22, 2008 at 12:29:50PM CEST:
I've noticed another problem with two packages in poky, prelink and
libvorbis. Both packages have areas where LDFLAGS=-all-static is
used.
The problem comes about since Poky sets CC to ccache gcc, then
libtool
puts the -static flag between ccache and gcc.
Thanks for the bug report, and especially for providing an example to
reproduce it!
libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT -
fsigned-char -DUSE_MEMORY_H -o decoder_example
decoder_example.o ../lib/.libs/libvorbis.a -lm /usr/lib/libogg.a
Confirmed. Fixed as below, committed, put you in THANKS.
Cheers,
Ralf
2008-04-22 Ralf Wildenhues [EMAIL PROTECTED]
Fix regression over 1.5.26 with ccache $CC -all-static.
* libltdl/config/ltmain.m4sh (func_mode_link): Add
$link_static_flag to compile_command and link_command only
later, instead of right after a possible compiler wrapper.
* tests/static.at (ccache -all-static): New test.
* THANKS: Update.
Report by Richard Purdie.
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd .. pwd`; cd tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
MAKE=make CC=gcc CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS= LD=/
usr/libexec/gcc/i686-apple-darwin9/4.0.1/ld LDFLAGS= LIBS=
LN_S=ln -s NM=/usr/bin/nm -p RANLIB=ranlib STRIP=strip
OBJEXT=o EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=g++
CXXFLAGS=-g -O2 CXXCPP=g++ -E F77= FFLAGS= FC= FCFLAGS=
GCJ= GCJFLAGS=-g -O2 _lt_pkgdatadir=/Users/gary/Devo/libtool--
master--0/+build/.. LIBTOOLIZE=/Users/gary/Devo/libtool--
master--0/+build/libtoolize LIBTOOL=/Users/gary/Devo/libtool--
master--0/+build/libtool tst_aclocaldir=/Users/gary/Devo/libtool--
master--0/+build/../libltdl/m4 -v 27
## -- ##
## libtool 2.2.3a test suite. ##
## -- ##
27. static.at:357: testing ...
../../tests/static.at:373: $CC $CPPFLAGS $CFLAGS -c a.c
stdout:
../../tests/static.at:375: $LIBTOOL --mode=link --tag=CC ./ccache $CC
$CFLAGS $LDFLAGS -all-static a.$OBJEXT -o a
--- /dev/null 2008-04-22 18:51:28.0 -0400
+++ /Users/gary/Devo/libtool--master--0/+build/tests/testsuite.dir/at-
stderr 2008-04-22 18:51:32.0 -0400
@@ -0,0 +1 @@
+libtool: link: warning: complete static linking is impossible in this
configuration
stdout:
libtool: link: ./ccache gcc -g -O2 a.o -o a
27. static.at:357: FAILED (static.at:375)
## - ##
## Test results. ##
## - ##
ERROR: 1 test was run,
1 failed unexpectedly.
Cheers,
Gary
--
())_. Email me: [EMAIL PROTECTED]
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_
PGP.sig
Description: This is a digitally signed message part
Re: libtool 2.2.2, ccache and -all-static
Hi Ralf, On Tue, 2008-04-22 at 21:43 +0200, Ralf Wildenhues wrote: Thanks for the bug report, and especially for providing an example to reproduce it! libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT -fsigned-char -DUSE_MEMORY_H -o decoder_example decoder_example.o ../lib/.libs/libvorbis.a -lm /usr/lib/libogg.a Confirmed. Fixed as below, committed, put you in THANKS. I've confirmed the fix, added it to Poky and dropped the hacks I had, thanks! Cheers, Richard
Re: [PATCH 365] Only complain that files are up-to-date with --force.
* Gary V. Vaughan wrote on Wed, Apr 23, 2008 at 12:18:39AM CEST: On 22 Apr 2008, at 16:16, Ralf Wildenhues wrote: +eval $1= Those double quotes are pretty superfluous, as they won't survive the eval. Not that they are a problem at all. :-) I quite like the fact that the say to the reader: this variable is being set to the empty string, Yes, I know. What you meant to write was eval $1=\\ so I'm inclined to leave them. My point is that it's not helpful trying to help the naive reader and confusing the slightly less naive one. Cheers, Ralf
Re: libtool 2.2.2, ccache and -all-static
* Gary V. Vaughan wrote on Wed, Apr 23, 2008 at 12:54:57AM CEST: 27. static.at:357: testing ... ../../tests/static.at:373: $CC $CPPFLAGS $CFLAGS -c a.c stdout: ../../tests/static.at:375: $LIBTOOL --mode=link --tag=CC ./ccache $CC $CFLAGS $LDFLAGS -all-static a.$OBJEXT -o a --- /dev/null 2008-04-22 18:51:28.0 -0400 +++ /Users/gary/Devo/libtool--master--0/+build/tests/testsuite.dir/at- stderr2008-04-22 18:51:32.0 -0400 @@ -0,0 +1 @@ +libtool: link: warning: complete static linking is impossible in this configuration stdout: libtool: link: ./ccache gcc -g -O2 a.o -o a 27. static.at:357: FAILED (static.at:375) Thanks. Fixed as below. (We could skip the test if link_static_flag is empty, but we'd have to ignore linker warning output for stupid systems anyway, so might as well just do that.) Sorry for not doing that right away. Cheers, Ralf 2008-04-23 Ralf Wildenhues [EMAIL PROTECTED] * tests/static.at (ccache -all-static): Ignore link warnings. Report by Gary V. Vaughan. diff --git a/tests/static.at b/tests/static.at index 1a51d0d..b5e9946 100644 --- a/tests/static.at +++ b/tests/static.at @@ -372,6 +372,6 @@ AT_DATA([a.c], AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore]) AT_CHECK([$LIBTOOL --mode=link --tag=CC ./ccache $CC $CFLAGS $LDFLAGS -all-static a.$OBJEXT -o a], -[], [ignore]) +[], [ignore], [ignore]) AT_CLEANUP
