Autoconf distributions and xz dependency
This reply should have been sent to the autoconf list rather than directly to Eric. The below is what I sent to Eric: On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. From what I have seen (and from its own documentation), the 'xz' implementation is not particularly portable and it requires considerable resources (e.g. memory) so it is unwise to discard the well-supported .gz format. The world will not particularly suffer if autoconf distribution files consume more storage than absolutely required. I would toss the .bz2 format if a format needs to be removed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
Hi! On 03/02/2012 05:45 AM, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. I want to second Bob Friesenhahn's opinion that it would be nice to keep at least a .gz release version. The xz-utils are not part of all standard distributions yet (I can just name the current Sabayon Linux and openSUSE 11.3), so I would prefer it if a standard tool like autoconf would not depend on it. Another issue I have with 2.68b is the dependency on m4 versions 1.4.6 - 1.4.10 or 1.4.16. One of the bad versions is installed on most machines that I use, therefore I would have to install a more recent version on all of them, sometimes even manually. Is this really a hard requirement, or is it possible to circumvent this somehow? What would happen if the bad versions would be used? Olaf -- Dr. rer. nat. Olaf Lenz Institut für Computerphysik, Pfaffenwaldring 27, D-70569 Stuttgart Phone: +49-711-685-63607 attachment: olenz.vcf signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Bob Friesenhahn wrote: This reply should have been sent to the autoconf list rather than directly to Eric. The below is what I sent to Eric: On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. From what I have seen (and from its own documentation), the 'xz' implementation is not particularly portable and it requires considerable resources Hi Bob, If you can demonstrate a portability problem, please provide details. From what I've heard (distributing xz-only compressed tarballs of coreutils, grep, diffutils, parted, etc.) there have been no problems building xz from source on the few systems for which it is not yet available pre-packaged. (e.g. memory) so it is unwise to discard the well-supported .gz I've heard that an embedded system user had trouble using xz to decompress because their system had only 32MB of RAM and no swap. However, even in that extreme case I think they found a work-around. Beware of outdated hearsay ;-) ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On Fri, 2 Mar 2012, Jim Meyering wrote: If you can demonstrate a portability problem, please provide details. From what I've heard (distributing xz-only compressed tarballs of coreutils, grep, diffutils, parted, etc.) there have been no problems building xz from source on the few systems for which it is not yet available pre-packaged. It does not successfully build using GCC on my Solaris 10 system, and not even with the workaround described in the INSTALL file. Regardless, building xz has certain documented requirements of its build environment (e.g. C'99 compiler and system headers) which can not be satisfied by all systems. I've heard that an embedded system user had trouble using xz to decompress because their system had only 32MB of RAM and no swap. However, even in that extreme case I think they found a work-around. From what I have heard, even hundreds of MB of RAM may not be sufficient. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Jim Meyering wrote: If you can demonstrate a portability problem, please provide details. From what I've heard (distributing xz-only compressed tarballs of coreutils, grep, diffutils, parted, etc.) there have been no problems building xz from source on the few systems for which it is not yet available pre-packaged. It does not successfully build using GCC on my Solaris 10 system, and not even with the workaround described in the INSTALL file. Did you report it? I've been building xz on sparc Solaris 10 with gcc since back when the program was called lzma. Regardless, building xz has certain documented requirements of its build environment (e.g. C'99 compiler and system headers) which can not be satisfied by all systems. Since gcc works just about anywhere, that's usually enough for anyone porting to the um... mature system vendors. I've heard that an embedded system user had trouble using xz to decompress because their system had only 32MB of RAM and no swap. However, even in that extreme case I think they found a work-around. From what I have heard, even hundreds of MB of RAM may not be sufficient. There are options to tune how much memory xz uses. Perhaps the people you heard from didn't know about those. xz has evolved in the last couple of years, so even if your anecdote represented a bug, it may well be fixed by now. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On Fri, 2 Mar 2012, Jim Meyering wrote: It does not successfully build using GCC on my Solaris 10 system, and not even with the workaround described in the INSTALL file. Did you report it? Yes. I've been building xz on sparc Solaris 10 with gcc since back when the program was called lzma. Maybe your GCC is different than mine. Mine uses the Solaris linker from /usr/ccs/bin/ld. This is for x86 rather than SPARC. From what I have heard, even hundreds of MB of RAM may not be sufficient. There are options to tune how much memory xz uses. Perhaps the people you heard from didn't know about those. xz has evolved in the last couple of years, so even if your anecdote represented a bug, it may well be fixed by now. I tried to test how much peak memory 'xz' uses to decompress the autoconf tarball but was (apparently) defeated by the strange way that 'xz' is linked. I will try again with a different tool this weekend. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On 03/02/2012 05:45 AM, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. Would only having xz introduce a chicken-and-egg bootstrapping problem? I notice xz-utils (http://tukaani.org/xz/) use Autoconf. - Rhys ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On 03/02/2012 10:24 AM, Jim Meyering wrote: Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Bob Friesenhahn wrote: I tried to test how much peak memory 'xz' uses to decompress the autoconf tarball but was (apparently) defeated by the strange way that 'xz' is linked. I will try again with a different tool this weekend. Ok, I have now measured how much memory the 'xz' I have here requires under Linux to decompress the autoconf beta tarball. It requires 67,184,168 bytes of heap memory. This seems to match the xz documentation for the -9 compression level. The autoconf tarball is not large enough to warrant using xz's -9 option. A simple xz -e (i.e., use the default of -6) should be fine. What's the magic to add to cfg.mk to get that change in default? I just used gnulib's maint.mk 'make beta' to make the 2.68b tarball, so if the defaults are wrong in maint.mk, maybe we should be fixing things upstream from autoconf. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Jim Meyering wrote: Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Bob Friesenhahn wrote: I tried to test how much peak memory 'xz' uses to decompress the autoconf tarball but was (apparently) defeated by the strange way that 'xz' is linked. I will try again with a different tool this weekend. Ok, I have now measured how much memory the 'xz' I have here requires under Linux to decompress the autoconf beta tarball. It requires 67,184,168 bytes of heap memory. This seems to match the xz documentation for the -9 compression level. The autoconf tarball is not large enough to warrant using xz's -9 option. A simple xz -e (i.e., use the default of -6) should be fine. To clarify, using --extreme (-e) with no compression preset is usually best. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On 03/02/2012 09:54 AM, Bob Friesenhahn wrote: the available computers might be donated computers from the late '90s or early 2000s Well, I dunno, I doubt whether this is much of a third-world issue; it's more of an backwater first-world issue. Let me try to explain. At UCLA we often get donations of discarded servers, and they're usually about five years old. Once we're done using them (the Solaris 8 boxes I'm talking about are a dozen years old and still ticking), nobody wants them except maybe computer museums, as the energy cost of running them far exceeds any economic value you get out of them, even in the third world. As I understand it, our Solaris 8 boxes are still alive mainly for licensing reasons, to run proprietary software that I'm not involved with and which we can't afford to upgrade. I expect this is the a common reason old Solaris 8 machines are kept running elsewhere too. Third-worlders tend to use cell phones and notebooks, not vintage AC-powered servers from the 1990s. And they tend not to worry about proper licensing. So it's first-world backwaters that have to deal with the old stuff, and we are the people most likely to benefit from .gz files. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On Friday 02 March 2012 11:09:13 Olaf Lenz wrote: On 03/02/2012 05:45 AM, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. I want to second Bob Friesenhahn's opinion that it would be nice to keep at least a .gz release version. The xz-utils are not part of all standard distributions yet (I can just name the current Sabayon Linux and openSUSE 11.3), so I would prefer it if a standard tool like autoconf would not depend on it. uhh, Sabayon does have xz-utils and has for quite a long time now. after all, it's simply Gentoo at its core, and Gentoo has had xz-utils for a long time. openSUSE has had xz-utils since 11.2. before that, they had lzma-utils. so do you have any other distros to list ? -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Jim Meyering wrote: It does not successfully build using GCC on my Solaris 10 system, and not even with the workaround described in the INSTALL file. Did you report it? Yes. Since it involves Solaris' ld, it's harder to reproduce and work around, as well as probably lower priority. I've been building xz on sparc Solaris 10 with gcc since back when the program was called lzma. Maybe your GCC is different than mine. Mine uses the Solaris linker from /usr/ccs/bin/ld. This is for x86 rather than SPARC. I've been using gcc-4.2.3 with /usr/ccs/bin/ld. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On Fri, 2 Mar 2012, Mike Frysinger wrote: uhh, Sabayon does have xz-utils and has for quite a long time now. after all, it's simply Gentoo at its core, and Gentoo has had xz-utils for a long time. openSUSE has had xz-utils since 11.2. before that, they had lzma-utils. so do you have any other distros to list ? -mike UnixWare, OpenServer 5 6 -- Tim RiceMultitalents t...@multitalents.net ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On Friday 02 March 2012 16:41:24 Tim Rice wrote: On Fri, 2 Mar 2012, Mike Frysinger wrote: uhh, Sabayon does have xz-utils and has for quite a long time now. after all, it's simply Gentoo at its core, and Gentoo has had xz-utils for a long time. openSUSE has had xz-utils since 11.2. before that, they had lzma-utils. so do you have any other distros to list ? UnixWare, OpenServer 5 6 yes, it is trivial to name all sorts of old non-Linux OS's that lack xz support (ignoring the manual d/l + build of xz-utils). this sub-thread was not about that. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; What problem are y'all trying to solve here? Is gnu.org running out of disk space or bandwidth? I hope you're not just trying to save disk space. I did a little math here and it looks like xz might save you 5 months of waiting for disk prices to drop. Same $/GiB either way. A better argument is the one behind RPM moving to xz: so they can keep adding bigger and more packages without moving to a second DVD. But, I don't see that applying to gnu.org. I still use systems[*] that don't have tar -J, and am likely to continue doing so for many years to come. Installing xz isn't a big deal, but typing the longer commands needed for separate decompression and untarring is. [*] The one likely to cause me the most problems is CentOS 5, replaced only about a year ago, which will still be receiving bug fixes for another 5 years. Given that we still have CentOS 3 boxes in service despite the OS being EOL'd more than a year ago, I'd say I'm going to be without tar -J everywhere until the third tech bubble hits in ~2019, assuming Wall Street keeps the current schedule. OS X Lion, released not that long ago, lacks gnutar -J, too. Apple being Apple, Lions will probably be endangered way before 2019, but still... ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf-2.68b released [beta]
On Fri, 2 Mar 2012, Mike Frysinger wrote: i don't think that matters. bzip2 is often not installed by default, nor is gcc or g++ or any other development program. i find it hard to swallow that this is even a small obstacle to someone who is installing autoconf manually by fetching the tarball and running configure+make. It is pretty common to find myself on a system with a working compiler and tools, but not the exact versions of autoconf, automake, and libtool that my projects need. Projects which don't store generated files in the source control repository suffer additional pain if it becomes more difficult to install autoconf, automake, and libtool on whatever machines they happen upon so that the project may be built. More pain results in less portable projects which have not been tested on as many operating systems and types of machines. Gzip is almost universally available so I don't think that distribution support for it should be dropped by autotools. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On 03/02/2012 04:48 PM, Warren Young wrote: On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; What problem are y'all trying to solve here? Is gnu.org running out of disk space or bandwidth? No, space and bandwidth are not the primary driver. A better argument is the one behind RPM moving to xz: so they can keep adding bigger and more packages without moving to a second DVD. But, I don't see that applying to gnu.org. Actually, this really is part of the reason - since xz is technically superior to gzip (better compression, same decompression speeds), we are doing users a favor by getting xz installed and commonly available in more places. But enough people have complained, that for at least 2.69, I will still ship a .gz tarball. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Eric Blake ebl...@redhat.com wrote on Fri, 2 Mar 2012 at 17:10:17 -0700 in 4f516169.9010...@redhat.com: Actually, this really is part of the reason - since xz is technically superior to gzip (better compression, same decompression speeds), we are doing users a favor by getting xz installed and commonly available in more places. Generally speaking, if you think you are doing a favor by adding a requirement, most people will disagree with you. --jh...@mit.edu John Hawkinson ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On 3/2/2012 5:10 PM, Eric Blake wrote: we are doing users a favor by getting xz installed and commonly available in more places. I went through both the .Z - .gz and .gz - .bz2 transitions. I recall a longer overlap period where major archive sites had everything in both the new and previous forms. I don't much care if .gz goes away now, as .Z did before it. I'd like to see a .bz2 option for everything I have to manually untar for at least another few years. The thing about the RPM example is that a new rpm program is installed by the distro that contains the new-format RPMs. You can't reliably install binary RPMs built on a newer system on an older one, so Linux distro makers can move to newer tech faster. You can't make the same argument for software installed from source. A lot of the users of such packages are bleeding edge folk, like yourself, but a lot are also people stuck on marginalized systems where they need to upgrade something and can't get a binary package, so they have to build from source. Folk in that latter class are likely to also be missing tar -J. Sorry to be a speedbump. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
Warren Young war...@etr-usa.com writes: I went through both the .Z - .gz and .gz - .bz2 transitions. I recall a longer overlap period where major archive sites had everything in both the new and previous forms. At least in my corner of the software world, no .gz - .bz2 transition never happened. I see occasional use of .bz2, but it's a definite minority. I don't much care if .gz goes away now, as .Z did before it. I'd like to see a .bz2 option for everything I have to manually untar for at least another few years. .Z went away because of annoying software patent issues at the time, which was the compelling case for gzip. Personally, I fail to see a similar compelling case for xz. It's a much more complex but nicer and more powerful compression algorithm, sure. But there doesn't seem to be any horribly important reason to use it for typical open source software distributions where the data size is quite small, as opposed to, say, scientific data sets where the savings could be substantial. I'm planning on looking at it seriously for log compression, where I want to squeeze GBs (or more) of data into smaller disk, but so far for my own projects I haven't seen any reason to move off of xz. My typical free software distribution is on the order of 200KB to 2MB, at which point any savings from xz is purely noise and the disruption of switching to something new that not everyone has readily available seems overriding. It's fine with me for Autoconf to do whatever the Autoconf maintainers feel like doing; part of the fun of free software is doing things the way that you want to do them whether or not other people agree with the logic of your case. :) Or just because it's fun. I use Debian and have xz and an appropriate GNU tar readily available and it's all the same to me. But I'm fairly unconvinced by the larger argument that free software developers should move to xz and away from gzip. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
touching dependency files, take 2
Let's see if these are the right lists It's partly autoconf because autoconf stages dummy dependency files so the make include function won't choke. It is partly make because I find it a bit tricky getting the dependencies just right. It is, I think, mostly an automake question since I think that the machinery behind the AMDEP/DEPDIR configury stuff is automake. The issue is that I have this tool that takes multiple input files and produces multiple output files. make, of course, was conceived with the idea that each production rule produces one output file. The workaround is to figure out how to have one target file represent the production of the many, often done with stamp files. e.g. target : $(deplist) touch $@-temp ; $(do-stuff) ; mv $@-temp $@ $(target_list) : target This is all well and good when dealing with yacc or lex where the number of inputs and outputs is fairly well constrained. My tool is not so well constrained. So I took a page from GCC. I use -M to tell it to produce make file friendly dependency files. But I took it a step farther, and that's what leads to this what-is-the-best-approach question. (I'm getting there.) The make fragment produced contains a list of sources, a list of targets, a sentinel target and the dependency file itself. The sentinel and the dependency fragment may be the same file. Here's an abbreviated example: t = output ... s = input ... .deps/output-done : $(s) $(t) : .deps/output-done @: the main makefile is responsible for the actual .deps/output-done rule. It would be nice to not have to have that basically empty production rule, but I haven't found a way to avoid it. Without it, you get no rule to make output errors. Question 1: Is there a way around this empty rule? When -MP is added to the command line, I now produce some phony rules: .PHONY : clean-.deps/output-done clean-.deps/output-done : rm -f $(t) touch -t 199912312359 .deps/output-done I'm not happy with that. This is an example where the sentinel file is the dependency file. Were they different, then it would be: t = output ... s = input ... stamp-foo : $(s) $(t) : stamp-foo @: .PHONY : clean-stamp-foo clean-stamp-foo : rm -f stamp-foo $(t) I'm also unhappy with this because I now have this stamp file wart, but I also don't have the touch -t 199912312359 wart. Question 2: Is there a better way? I'd also like to add a line to that fragment: ag_clean_targets += clean-stamp-foo but it isn't portable. So, pending the decade wait for the += make operator, there must be ways to test for make program capabilities. Question 3: I'm sure it's obvious and I'm just oblivious, but how do I tell if the current make supports += at configure time? Of course, it isn't clear that my clients could use it anyway since they'd have to construct the list for non-+= supporting platforms. This renders the utility of $(ag_clean_targets) to be rather small. Any suggestions? Thank you!! Regards, Bruce ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On Fri, 02 Mar 2012 16:48:07 -0700 Warren Young war...@etr-usa.com wrote: I still use systems[*] that don't have tar -J, and am likely to continue doing so for many years to come. Installing xz isn't a big deal, but typing the longer commands needed for separate decompression and untarring is. Exactly. And learning yet another unizipping command line is not now and never will be worth my time. It might become necessary, but that's another story. There are other tars and other paxes. I use NetBSD pax. It doesn't support xz and likely won't until and unless it becomes the dominant format. Is it GNU's prerogative to force changes like this, and to make other free software less convenient to use? If you live, and autoconf developers do, at the cutting edge of new releases, you of course know about xz. I had to resort to google and wikipedia to even know what it was, because the site whose tarball I needed didn't even bother to note what it was. (Note that it's still pretty common for websites to explain what a .pdf is, and where to download the Acrobat Reader.) --jkl ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoconf distributions and xz dependency
On Friday 02 March 2012 20:08:54 James K. Lowden wrote: On Fri, 02 Mar 2012 16:48:07 -0700 Warren Young wrote: I still use systems[*] that don't have tar -J, and am likely to continue doing so for many years to come. Installing xz isn't a big deal, but typing the longer commands needed for separate decompression and untarring is. Exactly. And learning yet another unizipping command line is not now and never will be worth my time. It might become necessary, but that's another story. that's a weak argument. the command line interface to gzip/bzip2/xz are largely the same on purpose. the -d -c -z -f -k -[0..9] -l -v -V -q -t -h flags all do the same thing, and really most people use a very small subset of those. xz -dc foo.tar.xz | tar xf - xzcat foo.tar.xz | tar xf - this largely sounds like get off my lawn -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
configure from autoconf 2.68b loops on NetBSD 5.1 amd64 (test 75) (was: Re: autoconf 2.68b loops on Solaris 10 sparc (test 75))
On 03/02/2012 08:53 AM, Paul Eggert wrote: The symptoms are: $ cd tests; make check TESTSUITEFLAGS=75 make check-local /bin/bash ./testsuite 75 ## -- ## ## GNU Autoconf 2.68b test suite. ## ## -- ## 75: Configure re-execs self with CONFIG_SHELL and it hangs until I do a ^C. The same test hangs on NetBSD 5.1 as well :-( Regards, Stefano
Re: bug#10925: Perl version problem in autoconf-2.68b
Hi Paul, Eric. Paul Eggert wrote: Solaris 8 ships with Perl 5.005_03. This satisfies Autoconf 'configure', which requires only 5.005_03 or better. But lib/Autom4te/Getopt.pm and lib/Autom4te/General.pm require 5.006_002. As I can test with at most with perl 5.6.2 (and no older versions), I tend to require the 5.6.2 version in any new perl file, or any existing file I do non-trivial modifications upon. Eric Blake wrote: From those lists, the two projects share Channels.pm, Getopt.pm, and Struct.pm. But Getopt.pm originates its minimum of 5.6.2 thanks to autoconf commit c3797b86ccbd9. Does lowering the minimum requirement to 5.5 fix things, or do we need to revert that patch to actually re-add the workaround that was dropped by that commit bumping to a newer version of perl? I've no idea, since I cannot test with 5.5. Also, Automake already requires perl 5.6 globally (and check for it in its configure), so I don't think its appropriate to introduce a workaround for a perl version it won't use anyway. Sorry. Also, note that the workaround removed in c3797b86ccbd9 was severely broken to begin with (that is explained in the commit message); re-introducing it only to make autoconf buildable out-of-the box on an obsolescent Solaris box seems a very bad idea. On the top of all that: Automake is a maintainer tool, so it's OK for it to have requirements tighter w.r.t. older tools that the ones in place for its generated Makefiles. After all, Autoconf is already requiring a fairly modern GNU m4, so why not require perl 5.6 as well? In conclusion, I'm quite oriented to close this bug report as a wontfix. Regards, Stefano
Re: bug#10925: Perl version problem in autoconf-2.68b
Hi Eric.
On 03/02/2012 04:08 PM, Eric Blake wrote:
On 03/02/2012 07:15 AM, Stefano Lattarini wrote:
Also, note that the workaround removed in c3797b86ccbd9 was severely
broken to begin with (that is explained in the commit message);
re-introducing it only to make autoconf buildable out-of-the box on
an obsolescent Solaris box seems a very bad idea.
On the top of all that: Automake is a maintainer tool, so it's OK for
it to have requirements tighter w.r.t. older tools that the ones in
place for its generated Makefiles. After all, Autoconf is already
requiring a fairly modern GNU m4, so why not require perl 5.6 as well?
In conclusion, I'm quite oriented to close this bug report as a
wontfix.
That's fair for automake. Paul, would it be okay if for autoconf we
borrow the same configure check as automake is using, and globally bump
the requirement to be consistent across the autotools? Technically, you
can use autoconf without automake, so automake requiring newer than
autoconf is possible; but since the tools are generally used together,
being consistent up front can't hurt.
Stefano, is it worth factoring the automake perl version check into a
separate .m4 file that can then be shared across automake and autoconf,
in the same manner that Getopt.pm is shared?
Not sure if it is worth it -- it's a very dumb check actually:
AC_PATH_PROG([PERL], [perl])
if test -z $PERL; then
AC_MSG_ERROR([perl not found])
fi
# Save details about the selected perl interpreter in config.log.
AM_RUN_LOG([$PERL --version])
$PERL -e 'require 5.006;' || {
AC_MSG_ERROR(
[perl 5.6 or better is required; perl 5.8.2 or better
is recommended. If you have several perl versions
installed, select the one Automake should use using
./configure PERL=/path/to/perl])
}
Maybe, if you think it would be worth it, you could generalize and improve
this check a bit, and make it available (from Autoconf 2.70 onwards) as a
(undocumented at first?) autoconf macro, say:
AC_PATH_PERL([MINIMAL-VERSION=5.0], [LIST-OF-NAMES=perl perl5], ...)
This could be easily re-used by automake without the need of hacky
inter-repository syncing... and in the long term probably by third
party packages as well, since I suspect that looking for a modern
enough perl is not such an uncommon action for configure scripts.
WDYT?
Thanks,
Stefano
Re: bug#10925: Perl version problem in autoconf-2.68b
On 03/02/2012 07:08 AM, Eric Blake wrote: Paul, would it be okay if for autoconf we borrow the same configure check as automake is using, and globally bump the requirement to be consistent across the autotools? Sure. If I understand things correctly, that means 'configure' will complain that Perl is out of date, and 'configure' will fail with a nice diagnostic. That's good enough for me.
Re: autoconf-2.68b released [beta]
On Thu, 1 Mar 2012, Eric Blake wrote: The GNU Autoconf team is pleased to announce the beta release of Autoconf 2.68b. Autoconf is an extensible package of M4 macros that [snip] On my UnixWare 7.1.4 box, the tests get stuck on 75: Configure re-execs self with CONFIG_SHELL Here are the processes running. UID PID PPID CLS PRI CSTIME TTY TIME COMD tim 17897 17884 TS 70 0 21:13:09 pts/50:00 gmake check-recursive tim 17883 17094 TS 85 0 21:13:09 pts/50:00 tee x.tst tim 29295 18042 TS 85 0 21:15:26 pts/50:00 cat tim 17946 17945 TS 70 0 21:13:09 pts/50:00 gmake check-local tim 17094 15128 TS 70 0 21:12:26 pts/50:00 sh tim 29359 29294 TS 70 0 21:15:27 pts/5 206:01 sh ./configure tim 18042 17946 TS 70 0 21:13:17 pts/50:00 /bin/ksh ./testsuite tim 15128 1 TS 70 0 16:46:05 pts/50:00 csh tim 17884 17883 TS 70 0 21:13:09 pts/50:00 gmake check tim 17908 17897 TS 70 0 21:13:09 pts/50:00 /bin/ksh -c fail= failco m='exit 1'; for f in x $MAKEFLAGS; do case $f in *=* tim 29294 18042 TS 70 0 21:15:26 pts/50:00 /bin/ksh ./testsuite tim 17945 17908 TS 70 0 21:13:09 pts/50:00 gmake check It looks like it is stuck on cat. Here is what is in tests/testsuite.dir/075 ... total 232 drwxr-xr-x2 tim trr 96 Mar 1 21:15 autom4te.cache -rwxrwxr-x1 tim trr 42 Mar 1 21:15 cfg-sh -rw-rw-r--1 tim trr 0 Mar 2 18:47 cfg-sh-has-run -rwxrwxr-x1 tim trr 51568 Mar 1 21:15 configure -rw-rw-r--1 tim trr 28 Mar 1 21:15 configure.ac -rwxrwxr-x1 tim trr 51487 Mar 2 18:47 configure.lineno -rw-rw-r--1 tim trr 207 Mar 1 21:15 testsuite.log ... Here is what is the contents of testsuite.log ... # -*- compilation -*- 75. m4sh.at:106: testing Configure re-execs self with CONFIG_SHELL ... ./m4sh.at:113: autoconf --force ./m4sh.at:123: env CONFIG_SHELL=./cfg-sh ./configure ... I'll try to do some more debugging in a couple of days. -- Tim RiceMultitalents t...@multitalents.net
