Re: Cleaning up libtool.m4, ltdl.m4 and configure.ac (Was: Re: FYI: Fixlet for missing braces around sys_search_path)
On Fri, 29 Apr 2005, Dalibor Topic wrote: On a side note, would there be some interest in patches cleaning up libtool.m4 / ltdl.m4 for autoconf 2.59 warnings? I run the latest released autotools with -Wall in kaffe's developers/autgen.sh script, and a lot of the pages and pages of warnigns for deprecated autoconf constructs come from libtool.m4. :( You are saying that libtool should *require* a newer version of Autoconf in order to be used? Sometimese a little deprecation is a good thing. I think that the warnings are not there simply due to sloth ... Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Cleaning up libtool.m4, ltdl.m4 and configure.ac
Ralf Wildenhues wrote: Hallo Ralf, We advertise Autoconf-2.50 and Automake-1.4 compatibility within branch-1-5. branch-2-0 does not do that any more, neither has it (most of) your warnings. IIRC there was only one left and it could only be solved with CVS autoconf, not sure ATM. Great! Thanks a lot, that's excellent news, making me look happily forward to 2.0. :) Unfortunately, while it is possible to simply autoupdate configure.ac and ltdl.m4 (by calling it configure.ac) [1], it is not possible to autoupdate libtool.m4 as the hacks around the lack of support for the java language in autoconf seem to whack autoupdate into some endless m4 loop. Well, at least 17 h long loop that I chose to terminate this morning :) This is a bug. Could you please post a recipe to reproduce it so we may at least find out which tool (M4, Autoconf, Automake, Libtool) is buggy? Sure. Get libtool 1.5.16-tar.gz. In libtool 1.5.16 source code dir: mkdir break-autoupdate && cp libtool.m4 break-autoupdate/configure.ac && cd break-autoupdate && autoupdate The definition of what constitues a bug fix is being bent ways at times, but if you ask me, no such reordering should take place, be it only because then we'd have to increase libtool.m4's serial which then made the universe collapse because our serial numbering would break. :-> That's a pretty good reason, I wouldn't want the universe to collapse :) Please look at branch-2-0 or even HEAD if you consider involved changes. I think I'll wait for 2.0 to see if making such involved changes makes sense any more. It sounds like 2.0 will solve my main pedantic -Wall warning gripe, anyway, so ... cheers, dalibor topic
Re: Small fix for 1.5.16 to turn off installation on default
* Dalibor Topic wrote on Fri, Apr 29, 2005 at 12:56:00PM CEST: > Ralf Wildenhues wrote: > > > >I am very sorry for this. I can push out a 1.5.18 with one of your > >fixes, but I don't think I can manage to do it this weekend and I'm gone > >most of next week. > > Ralf, thank you very much for taking care of libtool's 1.5 branch and > pushing regular releases out with the team. [1] Would a 1.5.18/1.5.16.1 > with just that single fix be faster to get out, by chance? Please note the bug has not been fixed /yet/. > [1] /me waves to pogma FWIW, I do have some time this weekend, and maybe that would be sufficient, too, but I usually plan for spare time, and moreover, I don't have a buffer after Monday. Also, putting in Alexandre's patch would be a nice thing to have, but definitely worth plenty of testing. I do have scripts for semi-automatic testing of about 7 different configurations on 4 arches in place, but they do take time, and then there is win32. I cannot test it automatically yet (need to reboot my laptop), which is one of the reasons I am pushing for the cross compile changes. Regards, Ralf
Re: Cleaning up libtool.m4, ltdl.m4 and configure.ac
Hi Dalibor, * Dalibor Topic wrote on Fri, Apr 29, 2005 at 12:51:00PM CEST: > > On a side note, would there be some interest in patches cleaning up > libtool.m4 / ltdl.m4 for autoconf 2.59 warnings? I run the latest > released autotools with -Wall in kaffe's developers/autgen.sh script, > and a lot of the pages and pages of warnigns for deprecated autoconf > constructs come from libtool.m4. :( We advertise Autoconf-2.50 and Automake-1.4 compatibility within branch-1-5. branch-2-0 does not do that any more, neither has it (most of) your warnings. IIRC there was only one left and it could only be solved with CVS autoconf, not sure ATM. > Unfortunately, while it is possible to simply autoupdate configure.ac > and ltdl.m4 (by calling it configure.ac) [1], it is not possible to > autoupdate libtool.m4 as the hacks around the lack of support for the > java language in autoconf seem to whack autoupdate into some endless m4 > loop. Well, at least 17 h long loop that I chose to terminate this > morning :) This is a bug. Could you please post a recipe to reproduce it so we may at least find out which tool (M4, Autoconf, Automake, Libtool) is buggy? > My amateur suggestion would be to try to split libtool.m4 into several > m4 files, like gettext does it for their m4 macros. That would make > autoupdating parts of it at least feasible. FWIW, branch-1-5 is not supposed to receive anything but bug fixes. The definition of what constitues a bug fix is being bent ways at times, but if you ask me, no such reordering should take place, be it only because then we'd have to increase libtool.m4's serial which then made the universe collapse because our serial numbering would break. :-> Please look at branch-2-0 or even HEAD if you consider involved changes. Also, please note that the very reason I work on bugs against branch-1-5 is that many of them turn out to be present in the other branches as well. Regards, Ralf
Re: Small fix for 1.5.16 to turn off installation on default
Ralf Wildenhues wrote: Hi Dalibor, Andreas, others, I am very sorry for this. I can push out a 1.5.18 with one of your fixes, but I don't think I can manage to do it this weekend and I'm gone most of next week. Moin Ralf, Moin Andreas, Ralf, thank you very much for taking care of libtool's 1.5 branch and pushing regular releases out with the team. [1] Would a 1.5.18/1.5.16.1 with just that single fix be faster to get out, by chance? cheers, dalibor topic [1] /me waves to pogma
Cleaning up libtool.m4, ltdl.m4 and configure.ac (Was: Re: FYI: Fixlet for missing braces around sys_search_path)
Ralf Wildenhues wrote: Hi Dalibor, * Dalibor Topic wrote on Thu, Apr 28, 2005 at 06:20:34PM CEST: here is another patch from Kaffe's libtool patch chest, which adds the missing braces around $sys_search_path in the definition of LTDL_SYSSEARCHPATH. That fixes libtool for at least one platform, though I don't recall which any more :( That does not matter. I hate inconsistent macro option quoting, one should do it even for the trivial cases just to get used to it, because the times when an option should _not_ be quoted are very much exceptions and should IMNSHO be clearly documented so. Moin Ralf, Thanks a lot for fixing the quotes on all of them! On a side note, would there be some interest in patches cleaning up libtool.m4 / ltdl.m4 for autoconf 2.59 warnings? I run the latest released autotools with -Wall in kaffe's developers/autgen.sh script, and a lot of the pages and pages of warnigns for deprecated autoconf constructs come from libtool.m4. :( Unfortunately, while it is possible to simply autoupdate configure.ac and ltdl.m4 (by calling it configure.ac) [1], it is not possible to autoupdate libtool.m4 as the hacks around the lack of support for the java language in autoconf seem to whack autoupdate into some endless m4 loop. Well, at least 17 h long loop that I chose to terminate this morning :) My amateur suggestion would be to try to split libtool.m4 into several m4 files, like gettext does it for their m4 macros. That would make autoupdating parts of it at least feasible. Many thanks for reporting all these bugs. Are there any other libtool-related patches you have in kaffe? (The static *BSD dlopen bug is still open, I don't know yet how to fix it.) Those were the three ones I had for 1.5. Thanks for the fast reply! cheers, dalibor topic [1] autoupdate makes the updated files require autoconf 2.59, though, I don't know if that's a problem for the 1.5 branch.
FYI: Fixlet for missing braces around sys_search_path
Hi Dalibor, * Dalibor Topic wrote on Thu, Apr 28, 2005 at 06:20:34PM CEST: > > here is another patch from Kaffe's libtool patch chest, which adds the > missing braces around $sys_search_path in the definition of > LTDL_SYSSEARCHPATH. That fixes libtool for at least one platform, though > I don't recall which any more :( That does not matter. I hate inconsistent macro option quoting, one should do it even for the trivial cases just to get used to it, because the times when an option should _not_ be quoted are very much exceptions and should IMNSHO be clearly documented so. I will send a patch regarding Autoconf documentation to the autoconf-patches list, and have applied the attach patches to all three libtool branches, which change all such invocations. Many thanks for reporting all these bugs. Are there any other libtool-related patches you have in kaffe? (The static *BSD dlopen bug is still open, I don't know yet how to fix it.) Regards, Ralf > 2004-03-12 Riccardo Mottola <[EMAIL PROTECTED]>, > Michael Koch <[EMAIL PROTECTED]> > > * libltdl/acinclude.m4 (LTDL_SYSSEARCHPATH): Brace > $sys_search_path argument. 2005-04-29 Ralf Wildenhues <[EMAIL PROTECTED]> * ltdl.m4 (all over): Quote all arguments to AC_DEFINE and AC_DEFINE_UNQUOTED consistently. Reported by Michael Koch <[EMAIL PROTECTED]>, Riccardo Mottola <[EMAIL PROTECTED]>, and Dalibor Topic <[EMAIL PROTECTED]>. Index: m4/ltdl.m4 === RCS file: /cvsroot/libtool/libtool/m4/ltdl.m4,v retrieving revision 1.27 diff -u -r1.27 ltdl.m4 --- m4/ltdl.m4 4 Apr 2005 12:12:25 - 1.27 +++ m4/ltdl.m4 29 Apr 2005 08:44:04 - @@ -39,7 +39,7 @@ if test "x$with_included_ltdl" = xno; then # If the included ltdl is not to be used. then Use the # preinstalled libltdl we found. - AC_DEFINE([HAVE_LTDL], 1, + AC_DEFINE([HAVE_LTDL], [1], [Define this if a modern libltdl is already installed]) LIBLTDL=-lltdl fi @@ -295,7 +295,7 @@ ]) if test -n "$libltdl_cv_shlibext"; then m4_pattern_allow([LT_MODULE_EXT])dnl - AC_DEFINE_UNQUOTED(LT_MODULE_EXT, "$libltdl_cv_shlibext", + AC_DEFINE_UNQUOTED([LT_MODULE_EXT], ["$libltdl_cv_shlibext"], [Define to the extension used for runtime loadable modules, say, ".so".]) fi ])# LT_SYS_MODULE_EXT @@ -314,7 +314,7 @@ [lt_cv_module_path_var], [lt_cv_module_path_var="$shlibpath_var"]) if test -n "$lt_cv_module_path_var"; then m4_pattern_allow([LT_MODULE_PATH_VAR])dnl - AC_DEFINE_UNQUOTED(LT_MODULE_PATH_VAR, "$lt_cv_module_path_var", + AC_DEFINE_UNQUOTED([LT_MODULE_PATH_VAR], ["$lt_cv_module_path_var"], [Define to the name of the environment variable that determines the run-time module search path.]) fi ])# LT_SYS_MODULE_PATH @@ -342,7 +342,7 @@ fi done m4_pattern_allow([LT_DLSEARCH_PATH])dnl - AC_DEFINE_UNQUOTED(LT_DLSEARCH_PATH, "$sys_dlsearch_path", + AC_DEFINE_UNQUOTED([LT_DLSEARCH_PATH], ["$sys_dlsearch_path"], [Define to the system default library search path.]) fi ])# LT_SYS_DLSEARCH_PATH @@ -366,7 +366,7 @@ fi ]) if test x"$libltdl_cv_preloaded_symbols" = xyes; then - AC_DEFINE(HAVE_PRELOADED_SYMBOLS, 1, + AC_DEFINE([HAVE_PRELOADED_SYMBOLS], [1], [Define if libtool can extract symbol lists from object files.]) fi ])# _LT_CHECK_DLPREOPEN @@ -534,7 +534,7 @@ fi if test x"$libltdl_cv_need_uscore" = xyes; then - AC_DEFINE(NEED_USCORE, 1, + AC_DEFINE([NEED_USCORE], [1], [Define if dlsym() requires a leading underscore in symbol names.]) fi ])# LT_FUNC_DLSYM_USCORE
Re: Small fix for 1.5.16 to turn off installation on default
Hi Dalibor, Andreas, others, * Dalibor Topic wrote on Thu, Apr 28, 2005 at 02:04:57PM CEST: > > I've updated Kaffe [1] CVS head to libtool 1.5.16 and noticed that it > broke make distcheck of Kaffe by installing and leaving libltdl files > around in $prefix/share/libtool, which 1.5.14 didn't do. * Andreas Schwab wrote on Thu, Apr 28, 2005 at 06:48:10PM CEST: > As a user of the libltdl library I surely don't want to install the > libltdl data files as part of my project. You are both correct. This is a regression from 1.5.14. :-( It's present in branch-2-0 and HEAD as well. It's also a very serious bug for distributions, as it might go unnoticed and then hurt completely unrelated packages. I am very sorry for this. I can push out a 1.5.18 with one of your fixes, but I don't think I can manage to do it this weekend and I'm gone most of next week. Regards, Ralf PS: I have applied this patch to HACKING (HEAD, branch-2-0): 2005-04-29 Ralf Wildenhues <[EMAIL PROTECTED]> * HACKING: Updated. Index: HACKING === RCS file: /cvsroot/libtool/libtool/HACKING,v retrieving revision 1.16 diff -u -r1.16 HACKING --- HACKING 26 Apr 2005 11:55:12 - 1.16 +++ HACKING 29 Apr 2005 06:27:35 - @@ -380,8 +380,9 @@ fetch new versions of the files that are maintained outside of libtool. -* Run `make distcheck'. If there are any problems, fix them and start - again. +* Run `make distcheck' and `make distcheck + DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install'. If there are any + problems, fix them and start again. * Run ./commit from the source tree.
