Re: Evaluating arithmetic expressions with macros (eval)
On Thu, Oct 12, 2023 at 04:33:54PM +0100, Peter Hull wrote: > On Thu, 12 Oct 2023 at 15:56, Sébastien Hinderer > wrote: > > So according to that, I expected that autoconf would call m4 with the -P > > option and looked at my /usr/bin/autoconf script but it does not seem to > > contain any occurrence of -P. But perhaps that appears in a sourced file > > or so. > You're right! Possibly it is done by 'lib/m4sugar/m4sugar.m4' in the > source code. I'll leave it to someone who knows what they're talking > about to reply! Autoconf intentionally provides m4_ prefixes as the preferred spelling for the majority of m4 builtin macros - but it does so via the m4sugar prelude that manually renames things, rather than via m4 -P. In some cases, the original builtin name is still available as well, but intentionally undocumented. Thus, in your configure.ac file, both m4_eval(...) and eval(...) will do the same actions, but only m4_eval(...) complies with the manual (and although unlikely due to back-compat reasons, some future release of autoconf could decide to make eval(...) no longer do what you want). -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
Re: remaining tasks before Autoconf release
On Wed, Apr 19, 2023 at 02:14:05PM -0700, Paul Eggert wrote:
> +++ b/doc/autoconf.texi
> @@ -8808,18 +8808,20 @@ if possible. These types may include
> @code{blkcnt_t}, @code{dev_t},
>
> Also, arrange for a @command{configure} option @code{--enable-year2038}
> to request widening the type @code{time_t} as needed to represent file
> -wand other timestamps after January 2038. This widening is possible
> +wand other timestamps after mid-January 2038. This widening is possible
s/wand/and/ ?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: On time64 and Large File Support
[replying to the original post, because I'm not sure where else in the more recent activity on this thread would be more appropriate] On Fri, Nov 11, 2022 at 08:38:18AM +, Sam James wrote: > Hi all, > > In Gentoo, we've been planning out what we should do for time64 on glibc [0] > and concluded that we need some support in glibc for a newer option. I'll > outline > why below. > ... > > Indeed, the gnulib version of change #2 is exactly how we ended up with > wget/gnutls breaking [1]. I feel this shows that the only approach > "supported" by glibc right now is untenable. > [1] https://bugs.gentoo.org/828001 Now Fedora is also being hit by the gnutls ABI change due to time_t in public interfaces being silently changed. From an IRC conversation I had with Dan Berrange and Rich Jones (I think Rich mean i686 below): rjones (IRC): oh wow, the certificates created on i696 are not quite right . Validity: Not Before: Sat Sep 05 00:23:57 UTC 2703 Not After: Sun Sep 06 00:23:57 UTC 2703 just a few years too early i think this is looking like a gnutls regression, downgrading gnutls makes it work ... rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage but the very same call done from a demo program returns the right answer ... OMG, gnulib-- has silently changed gnutls to use 64-bit time_t ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t this is utterly insane -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: Subscribe
On Mon, Jul 11, 2022 at 09:05:24AM +0300, d...@collaboration.cafe wrote: > How can I subscribe to this mailing list, please? Like most GNU lists, you can subscribe on the list overview page: https://lists.gnu.org/mailman/listinfo/autoconf -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: autoconf-2.71 released [stable]
On 1/28/21 4:49 PM, Zack Weinberg wrote: > We are pleased to announce stable release 2.71 of Autoconf. FYI, at the time this release was made, we neglected the fact that https://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.* still pointed to the 2.69 release from 2012. I just fixed that today, using: $ build-aux/gnupload --to ftp.gnu.org:autoconf --symlink autoconf-2.71.tar.gz autoconf-latest.tar.gz --symlink autoconf-2.71.tar.gz.sig autoconf-latest.tar.gz.sig --symlink autoconf-2.71.tar.xz autoconf-latest.tar.xz --symlink autoconf-2.71.tar.xz.sig autoconf-latest.tar.xz.sig and meanwhile I'm seeing if gnulib will improve 'maint.mk' to pass --symlink-regexp in the suggested gnupload command it generates during 'make stable', so we don't forget this step for the next release. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: Licensing of Autoconf
On 10/12/20 7:32 PM, Jack Pearson wrote: Hello all! Thanks for all the great work you do. I was browsing the GNU Autoconf repo and became rather confused about what the license is for GNU Autoconf. File copyright headers say that the project is licensed under GPLv3+. That is correct, as documented in the NEWS for autoconf 2.65 (2009). However, the project website (http://savannah.gnu.org/projects/autoconf) says that it's licensed under GPLv2+. Thanks for spotting that; I flipped the switch and it is now correctly listing GPLv3+. I'm inclined to believe the copyright headers, but the main COPYING file is GPLv2. Is this significant? Autoconf installs both COPYING and COPYINGv3 for ease of use by other projects; but Autoconf itself is under COPYINGv3 (see Readme). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: autoconf-2.69c released [beta]
On 9/30/20 8:41 AM, Zack Weinberg wrote: >> Most probably either 'git-version-gen' or some use of 'git describe' >> can achieve this. > > I just built autoconf (the program) from a completely clean checkout > of git trunk, which is currently two commits after the v2.69c tag, and > it identified itself as "autoconf (GNU Autoconf) 2.69c.2-04d14". So > it appears to me that what you suggest, already happens. > > However, then I checked out git commit > 14265094af1614d9e359550ca4a4939e590a5dba and rebuilt the tree, and it > continued to identify itself as version 2.69c.2-04d14. I had to run > `git clean -xdf` and re-autoreconf before it would start identifying > itself as 2.69b.67-14265. So there *is* a bug somewhere in the build > process, where it fails to notice that the value of @VERSION@ ought to > change. Perhaps that's how Paul got 2.69.301-14265. Less of a bug and more an intentional thing. When developing autoconf, you don't want to have to frequently regenerate the world just because of a version number change. So the documented procedures for maintainers is that you have to autoreconf twice: the first time to get an autoconf that learns a version number for future output, but where generated files still have a version number inherited from whatever version of autoconf you bootstrapped with; the second time with the just-built autoconf so that all version numbers appear the same (both in generated comments and in what the second-built autoconf will produce). Ideas on streamlining that are welcome, but as we at least have a documented procedure (even if it is multi-step), it's not essential to fix before 2.70. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Knowing which tool is being run, from M4
On 8/5/20 2:35 PM, Zack Weinberg wrote: This feels like a stupid question but I’ve been failing to find the answer all day. Is there a way for M4 code (specifically in autoconf/general.m4, if it matters) to tell which command-line tool (autoconf, autoheader, etc.) is being run? Nothing obvious jumps out at me. Each command-line tool calls autom4te --language=XYZ, where the choice of language determines which other arguments are pre-loaded. Perhaps seeing if a particular witness macro is defined from a given language's presets is enough to deduce things, though? For example, the 'M4sugar' language is the base of the inheritance tree, so it is always loaded; the 'M4sh' language loads a definition of AS_INIT from m4sh.m4f (so if that macro is not defined, you are in m4sugar rather than m4sh); the 'Autotest' language loads autotest.m4f on top of M4sh (so seeing if AT_INIT is defined is a good witness); the 'Autoconf' language loads in autoconf.m4f on top of M4sh (so seeing if AC_INIT is defined is a good witness). On the other hand, autom4te doesn't have an 'Autoheader' language per se, but does define 'Autoheader-preselections', but that doesn't cause any extra files to be loaded or new macros to be defined, so offhand I don't see an easy witness to tell when autoheader is being run, and the autoheader binary calls autom4te --language=autoconf. It might be an interesting idea to add support for a well-documented macro (probably at the m4sugar namespace) that can be queried to learn the current language, and then updating autom4te or each binary that calls autom4te to use -Dm4_language=XYZ to then make that macro be a reliable indicator of which language flavor is being run under autom4te. But given the difference in release cycles between autoconf and automake, that may still not help you in the short term for learning when automake is running things (other than seeing if AM_INIT is defined). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: Who's the upstream owner of GNUmakefile?
On 8/4/20 10:07 AM, Eric Blake wrote: On 8/4/20 9:58 AM, Zack Weinberg wrote: I just pushed a commit that partially reverts a `make fetch'. Partially revert e54e3f90: restore use of $(MAKE) in error message. In commit 14d58bfd, the error message printed by the ‘abort-due-to-no-makefile’ rule in GNUmakefile was changed to refer to the value of ‘$(MAKE)’ instead of a literal ‘make’. A subsequent ‘make fetch’ (e54e3f90) clobbered this. Put it back. Clearly we need to send the change to this error message upstream, but I don't know who the upstream for this file is. GNUmakefile comes from gnulib (the gnumakefile module). It is one of the few files that has to be checked in to git rather than populated after bootstrap; which means that every time you update to a newer version of gnulib that happens to modify the file, it results in another checkin of GNUmakefile in autoconf. That's what 'make fetch' is intended to do. So, if you want a change to stick in that file, update the gnulib version first, then update autoconf to the newer version of gnulib containing that fix. Sorry, I'm confusing projects. Many projects have a bootstrap script from gnulib, and run gnulib-tool on initial checkout rather than storing gnulib artifacts in the project repo, in such projects, it is bootstrap, and not GNUmakefile, that must be checked into the repo. But autoconf does not use enough files from gnulib to currently make it worth using gnulib-tool on the fly; instead, it stores ALL files copied from gnulib directly into the autoconf.git during 'make fetch'. But the point remains, if you want a change to stick into a file that autoconf copied from gnulib, then make the change in gnulib first. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: Who's the upstream owner of GNUmakefile?
On 8/4/20 9:58 AM, Zack Weinberg wrote: I just pushed a commit that partially reverts a `make fetch'. Partially revert e54e3f90: restore use of $(MAKE) in error message. In commit 14d58bfd, the error message printed by the ‘abort-due-to-no-makefile’ rule in GNUmakefile was changed to refer to the value of ‘$(MAKE)’ instead of a literal ‘make’. A subsequent ‘make fetch’ (e54e3f90) clobbered this. Put it back. Clearly we need to send the change to this error message upstream, but I don't know who the upstream for this file is. GNUmakefile comes from gnulib (the gnumakefile module). It is one of the few files that has to be checked in to git rather than populated after bootstrap; which means that every time you update to a newer version of gnulib that happens to modify the file, it results in another checkin of GNUmakefile in autoconf. That's what 'make fetch' is intended to do. So, if you want a change to stick in that file, update the gnulib version first, then update autoconf to the newer version of gnulib containing that fix. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: M4sh tests 77 and 78 vs /bin/sh -> dash
On 3/12/20 3:53 PM, Zack Weinberg wrote: On further investigation, there is a concrete reason why autoconf 2.69 prefers SHELL=/bin/bash to SHELL=/bin/dash, namely that dash doesn't support $LINENO, necessitating a complicated and fragile workaround (see _AS_LINENO_PREPARE in lib/m4sugar/m4sh.m4). This has been the behavior for a very long time (since roughly 2008). Moreover, the changed behavior of autoconf trunk was not intentional; it's because commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf missed a direct use of $as_echo in _AS_DETECT_BETTER_SHELL, causing _AS_DETECT_BETTER_SHELL *not to work at all*! I'm still looking into why tests/testsuite malfunctions when run by dash, but right now I am inclined to say that the bug in _AS_DETECT_BETTER_SHELL should be fixed and then we should independently discuss whether it makes sense to prefer dash to bash. It *would* discourage people from writing bashisms in their configure.ac's and it *is* 30% faster than bash (on my computer, according to "time make check"), but not supporting $LINENO is a big loss. Here's a thought - now that we know that bash 5 has a severe bug where the presence of a file named '%sn' in the current working directory causes ./configure to fail (for any configure that uses $as-echo), should we teach _AS_DETECT_BETTER_SHELL to catch that bash bug and prefer dash (even with no LINENO support) over bash in that scenario? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: How should long messages be displayed
On 9/17/19 11:38 AM, Sébastien Hinderer wrote: > Dear all, > > One of my autoconf script has a long notice mesage, i.e. over 80 > characters. I am already using m4_normalize to be able to write the > message nicely in the configure.ac file, but at the moment the printed > message generates a very long line and I am wondering whether something > is recommended to deal with this situation? Do I have to insert an > end-of-line character explicitly in the string, or is there a way to let > autoconf format the notice messages nicely by itself as is done for help > strings? > > Many thanks in advance for any hint! Can you paste the actual portion of the configure.ac in question? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Making a path absolute portably
On 7/10/19 7:54 AM, Bob Friesenhahn wrote:
> On Wed, 10 Jul 2019, Sébastien Hinderer wrote:
>
>> Dear all,
>>
>> I'd need to compute the absolute path of srcdir in a portable way (it's
>> okay if it includes symlinks).
>>
>> Currently I use
>>
>> abssrcdir=$(cd "${srcdir}"; echo $PWD)
>> which seems to work fine.
>>
>> Is that considered portable enough?
>
> It appears that $PWD is a shell extension, so I don't think so.
No, POSIX requires that $PWD always be accurate, so that part is portable.
> Even
> the shell syntax being used to execute the external command is not very
> portable.
The use of $() instead of `` is fairly portable except to old Solaris
/bin/sh - since you asked on the autoconf list, if your usage is inside
a configure script, then we have probably already happened to re-execute
your script to be running inside a shell that supports $(), (but
surprisingly, autoconf doesn't actually yet guarantee support for $() by
default).
> In addition to that, if the cd "${srcdir}" fails, it would
> then capture the wrong directory.
>
> This syntax is proven to be portable and reliable:
>
> abssrcdir="`cd $srcdir && pwd`"
No, that still has problems if $srcdir contains whitespace or begins
with '-'; and also eats trailing newlines in an unusually-named
directory. Do you have to worry about that in practice? Probably not.
But being truly portable vs. good enough can be surprisingly hard.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Making a path absolute portably
On 7/10/19 6:45 AM, Sébastien Hinderer wrote:
> Dear all,
>
> I'd need to compute the absolute path of srcdir in a portable way (it's
> okay if it includes symlinks).
>
> Currently I use
>
> abssrcdir=$(cd "${srcdir}"; echo $PWD)
> which seems to work fine.
>
> Is that considered portable enough?
No, because it uses echo instead of printf and it forgot to quote
"$PWD". If $srcdir begins with '-' or contains \, behavior is
unspecified based on the problems of echo; if it begins with -, it could
cause problems with cd, and if it contains whitespace, then word
splitting is performed (after echo processes multiple arguments instead
of the intended single argument, abssrcdir would end up with a single
space in place of any run of space or tabs in the original). Then thanks
to $(), if $srcdir ends with one or more \n characters you lose those
bytes if you don't add then strip a sentinel. Of course, it's unusual
for someone to run your script with srcdir=-mean-name or even
srcdir=$'../../mean \\dir\n', so you may be able to overlook those
issues. Your next problem is that if $CDPATH is set in the environment,
and $srcdir is relative and matches a hit in CDPATH, then 'cd' produces
output in addition to your echo (not what you wanted). Finally, if the
cd fails (unusual, but possible if you don't have permissions to change
to the directory), you end up echoing your current location instead of
your intended location.
Fixing all of those items could be done with:
abssrcdir=$(unset CDPATH; cd -- "$srcdir" && printf %sX "$PWD") || fail
abssrcdir=${abcsrcdir%X}
but how much portability you actually have to worry about, vs. ignoring
as unlikely, may depend on context of how you expect $srcdir to be
populated.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Re-exec of $as_myself chooses wrong configure script from PATH
On 5/30/19 7:33 AM, Michael Orlitzky wrote:
> In the configure scripts that I'm generating, I see the following
> variable assignment:
>
> # Find who we are. Look in the path if we contain no directory
> # separator.
> as_myself=...
>
> Later, this may be used to re-exec the configure script with a better shell,
>
> exec $CONFIG_SHELL $as_opts "$as_myself" ${1+"$@"}
>
> But, consider the following scenario:
>
> * I have some other "configure" in my $PATH.
> * I have a shell that doesn't support LINENO.
> * I execute ./configure for some package by running "sh configure".
Executing 'sh configure' should execute whatever 'configure' is first on
your PATH, which is not ./configure unless '.' is early in your PATH.
Are you sure ./configure is even in the loop here to even get a chance
to compute $as_myself for a potential re-exec?
Does running 'sh ./configure' fix things for you?
>
> What happens in that case is that the "as_myself" computation fails to
> find a directory separator in "configure", and instead searches my path
> for a usable "configure". It finds one, but not the one I wanted to run!
> Now I have
>
> as_myself=/path/to/some/other/configure/script
>
> and then since my shell doesn't support LINENO, I wind up running
>
> $CONFIG_SHELL ... /path/to/some/other/configure/script
>
> In other words, I re-exec the wrong script entirely. This can be worked
> around by running "sh ./configure" instead of "sh configure", but leads
> to a great deal of head-scratching.
>
> Is this something that can (should?) be fixed?
I'm not convinced that you have fully described your setup in a way that
I can reproduce, yet.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: failure in building po/Makefile due to crippled sed
On 3/7/19 4:07 AM, Perry Hutchison wrote: > Feel free to direct me elsewhere if this is not the proper list > for this report. I have not found any similar reports, either > in the autoconf archives or elsewhere, but it's certainly possible > that I didn't look in the right place. As the creation of po/Makefile is due to code from the gettext project, your report will probably go further there. Autoconf is not the source of this particular sed command. > > In attempting to build some of the GNU development tools on a Linux > system that lacks them, I am encountering issues when config.status > attempts to generate Makefiles for "po" directories. For example, > this sed command (reformatted, and with some parts not relevant to > the current issue omitted): > > sed -e "/^POTFILES =/r $ac_dir/POTFILES" \ $ git grep 'sed .*/r' turns up nothing for autoconf.git sources, but DOES hit in m4/po.m4 in gnulib.git, where it is in turn kept in sync from upstream gettext. > -e "/^# Makevars/r $ac_given_srcdir/$ac_dir/Makevars" \ > -e "s|@POFILES@|$POFILES|g" \ > ... \ > -e "s|@POMAKEFILEDEPS@|$POMAKEFILEDEPS|g" \ > "$ac_dir/Makefile.in" > "$ac_dir/Makefile" > > produces this error message when executed (while attempting to build > GNU make): > > config.status: executing po-directories commands > config.status: creating po/POTFILES > config.status: creating po/Makefile > sed: -e expression #1, char 14: e/r/w commands disabled in sandbox mode That's a bummer that your system has a non-POSIX-compliant sed by default. I don't know where you'd complain to get that fixed, but POSIX requires '/address/r file' to work; we'll probably have to come up with ways to workaround your system's brain-dead policy, and could patch the autoconf documentation to mention this as a new portability pitfall of using POSIX-specified sed features. > config.status: creating build.sh > > leading me to suspect that this system's native sed has been crippled > to always operate in "sandbox" mode, even without "--sandbox" having > been specified on the command line. > > The resulting po/Makefile does not resemble Makefile.in at all. > Later on, when "./make DESTDIR=... install" descends into the po > directory: > > Making install in po > make[1]: *** No rule to make target 'install'. Stop. > > The same sed error message arises in attempting to build other GNU tools, > including gettext (which is a dependency of GNU sed, so I haven't been > able to build GNU sed to use in place of the system's crippled version). > > While the root cause of these failures is the broken sed, it would > certainly help if configure checked for such breakage and generated > a workaround when needed, e.g. replacing the above sed command with > something along the lines of: > > sed -e '/^POTFILES =/+1,$d' \ > -e "s|@POFILES@|$POFILES|g" \ > ... \ > -e "s|@POMAKEFILEDEPS@|$POMAKEFILEDEPS|g" \ > "$ac_dir/Makefile.in" > Temp1 > sed -e '1,/^POTFILES =/d' -e '/^# Makevars/+1,$d' \ > -e "s|@POFILES@|$POFILES|g" \ > ... \ > -e "s|@POMAKEFILEDEPS@|$POMAKEFILEDEPS|g" \ > "$ac_dir/Makefile.in" > Temp2 > sed -e '1,/^# Makevars/d' \ > -e "s|@POFILES@|$POFILES|g" \ > ... \ > -e "s|@POMAKEFILEDEPS@|$POMAKEFILEDEPS|g" \ > "$ac_dir/Makefile.in" > Temp3 > cat Temp1 "$ac_dir/POTFILES" Temp2 "$ac_given_srcdir/$ac_dir/Makevars" \ > Temp3 > "$ac_dir/Makefile" > rm Temp[123] That's up to the authors of the specific .m4 files that tried to use sed's r command. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why does autoupdate remove spaces after commas in AC_INIT only?
On 3/6/19 2:31 AM, Matthieu Poullet wrote: > Hello, > > I've just updated a bunch of configure.ac with autoupdate 2.69 and it > removes all spaces after commas in the AC_INIT macro and only in this > macro, e.g. > > diff --git a/flaim-ch8-10/configure.ac b/flaim-ch8-10/configure.ac > index baa0a1c..a724bbc 100644 > --- a/flaim-ch8-10/configure.ac > +++ b/flaim-ch8-10/configure.ac > @@ -1,8 +1,8 @@ > # -*- Autoconf -*- > # Process this file with autoconf to produce a configure script. > > -AC_PREREQ([2.62]) > -AC_INIT([flaim-projects], [1.0]) > +AC_PREREQ([2.69]) > +AC_INIT([flaim-projects],[1.0]) > AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > LT_PREREQ([2.2]) > LT_INIT([dlopen]) > > So my questions are: > - is it a bug? Not a functional bug. Due to m4 quoting rules (where unquoted spaces after , when collecting macro arguments are stripped), the following are identical in behavior: AC_INIT([a],[b]) AC_INIT([a],[b]) But as it does look different, a patch to avoid the reformatting would be accepted (however, I suspect such a patch would be extremely difficult to write, as autoupdate is using m4 to figure out which macros to rewrite, and m4 doesn't track how many spaces it discarded, for you to know how many spaces to add back). > - is it a feature/a best practice? if yes, does it mean that autoconf > recommends not using spaces after commas and why does it not touch the > other macros then? Style-wise, space after comma is more legible, but it is not required. As for why other macros are untouched, it is because autoupdate uses m4 to look for a select handful of macros, and intentionally ignores all other macros - the spaces are only eaten on the macros that autoupdate is looking for, and AC_INIT happens to be one of those macros. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Any chance to make a new autoconf release?
On 3/5/19 3:01 PM, Nicholas Clark wrote: > So let's say somebody from the community wanted to cut a new Autoconf > release. How would they go about doing it? HACKING gives a nice overview, but a good first hurdle to clear is to at least prove that you are capable of submitting patches (such as a patch to bump the copyright year to 2019, or to fix the testsuite failures that have been reported when using bash 5). The set of developers that have savannah push rights (and can thus upload a new tarball) is small, and I'm unlikely to hand that out to anyone that has not at least first shown on the list that they are trying to improve the current state of things with working patches. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Any chance to make a new autoconf release?
On 3/5/19 12:11 PM, Tomasz Kłoczko wrote: Hi, It is almost 7 years since last time autoconf have bee released. It is a lot well known issues and almost half of the test suite is failing because many software components moved forward. Is it any chance to make new release with what is already committed? Where is the problem? Why so long no one was able to make a new release? The problem, as always, is a lack of free time. I'm hoping to spend some of my $DAYJOB time on getting a release out the door, but am still waiting approval on that front; in the meantime, my weekends continue to be booked with real life to the point that I have not been able to devote enough time to a good release. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoreconf and depcomp
On 2/2/19 12:18 AM, bill-auger wrote: > when i run `autoreconf -ivf` and a 'depcomp' already file exists, > 'depcomp' gets added to 'am__DIST_COMMON' in ./Makefile.in - but when i > run `autoreconf -ivf` and the 'depcomp' file does not exist, it is > recreated automatically but is not added to 'am__DIST_COMMON' > > can someone advise me if i should be concerned about this quirky > behavior The contents of the generated Makefile.in result from Automake; so even though autoreconf belongs to Autoconf, any fix to this issue will have to come from a patch to Automake. Updating mail distribution accordingly. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Where are the original commands defined?
On 1/24/19 10:00 AM, Peng Yu wrote: > Please answer my original question. > > I know the things that you answered. > > - I know the problem is fPIC was not enabled. > - I use root as its just a docker image with root as the default login. > Even if you don't care whether the configure could have trashed your system, running configure as root may compute different answers to questions being probed, and cause the package to behave differently than if you had run configure as a normal user. In general, you do NOT want to run configure as root, regardless of whatever other sandboxing is in place. > > On Thu, Jan 24, 2019 at 9:54 AM Zack Weinberg wrote: >> >> On Thu, Jan 24, 2019 at 10:48 AM Peng Yu wrote: >>> I got the following int config.log when I run >>> http://git.savannah.gnu.org/cgit/bash.git/tree/configure >> ... >>> configure also runs many other commands. How to figure out where the >>> original commands are defined? Thanks. As in, how do you correlate the line numbers reported in config.log (such as the "configure:3772: gcc -g -finstrument-functions" in your snippet) back to the line numbers in configure.ac that produced those lines in configure? One trick is to add harmless witness statements in your configure.ac, such as: : probe point then after rerunning autoreconf, search for where the probe points got omitted, to see if their location in configure.ac is before or after the macro that expanded to the line in question. Use echo instead of : if you also need help in comparing the output of configure to spot where your probe point was executed in relation to the other things being run. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: What is the correct way to disable -O2?
On 1/23/19 12:10 PM, Peng Yu wrote:
> Hi,
>
> I had to use the following command to disable -O2 in the default of
> configure of bash.
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/configure
>
> CFLAGS='' -g -O0" ./configure
That's not the command you used. Maybe you meant:
CFLAGS="-g -O0" ./configure
but in that case, the GNU Coding Standards recommends that you spell it:
./configure CFLAGS="-g -O0"
(although the difference between two forms doesn't really matter to
configure scripts generated by Autoconf, it CAN matter to other
configure scripts that are still compliant with GCS).
>
> But the following command does not disable -O2. I think that -O2
> should be applicable to both C and C++ code, so it should have been
> set to CPPFLAGS as CPPFLAGS is for both C and C++ but CFLAGS is only
> for C.
Rather, CPPFLAGS is for the preprocessor (and affects C and C++ in that
both use the pre-processor), but gets processed prior to CFLAGS on the
command line, and compilers go with the last version set (so if CFLAGS
contains -O2, that overrides any -O0 in CPPFLAGS).
You are correct that setting CFLAGS="-g -O2" at configure time is the
preferred way to disable optimization; but whether it works or not also
depends on whether a particular project properly followed
Autoconf/Automake conventions. Your command line works on other
projects that use both of the autotools; but bash is notorious for using
Autoconf but not Automake; so it could very well be a bug specific to
bash's hand-rolled Makefile.in files for not obeying the GNU Coding
Standards in the same way that Automake would do for you automatically.
But that puts it as a question for automake and/or bash lists, rather
than the autoconf list.
>
> CPPFLAGS='' -g -O0" ./configure
>
> Could anybody let me know what is the standard way to disable -O2? I'd
> like a way that works for many autoconf-based packages besides just
> bash.
>
> Also, the configure file has this. Both -g and -O2 are compile-time
> options. Why are they used for linking? Is this usage correct?
They are more than just compile-time options - the linker needs to know
whether to include debug sections in the resulting binary.
>
> AUTO_LDFLAGS="-g ${GCC+-O2}"
>
The identifier AUTO_LDFLAGS is not present in Autoconf sources; at this
point, any question about its intent should be asked to the bash project
as the place that declared that variable.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure: error: C preprocessor "/lib/cpp" fails sanity check
On 11/16/18 5:30 PM, Fabiano Sidler wrote: Hi folks! When trying to configure (binutils and gmp, in that case), I'm getting this: === snip === checking how to run the C preprocessor... /lib/cpp configure: error: in `/home/luser/Downloads/binutils-2.26.1/libiberty': configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details. make[1]: *** [Makefile:7985: configure-libiberty] Error 1 make[1]: Leaving directory '/home/luser/Downloads/binutils-2.26.1' make: *** [Makefile:846: all] Error 2 === snap === Are you attaching the same config.log? If so, something is indeed odd, because looking at your attachment: config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = elux-devel uname -m = x86_64 uname -r = 4.14.39 uname -s = Linux uname -v = #1 SMP Fri Jul 20 13:35:34 CEST 2018 Okay, you've told us your kernel,... configure:4111: checking for gcc configure:4127: found /usr/local/bin/gcc configure:4138: result: gcc configure:4367: checking for C compiler version configure:4376: gcc --version >&5 gcc (GCC) 5.4.0 and it looks like you are using a self-built gcc, configure:14766: checking whether to enable maintainer-specific portions of Makefiles configure:14775: result: no configure:15032: creating ./config.status ## -- ## ## Running config.status. ## ## -- ## ... configure: exit 0 but this config.log says that configure ran to completion, without any warning about /lib/cpp failing a sanity check, which makes it hard to see the "more details" that stdout/stderr said we should be looking for in evidence why configure failed. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Arguemnts to configure
On 10/2/18 10:15 AM, Sébastien Hinderer wrote: Dear all, Is there a way to add a new "directory category", in addition to bindir, libdir, etc.? Which directory are you thinking? Is it standardized somewhere, like GNU Coding Standards, Linux File System, or similar? If it is worthwhile, autoconf should be providing that directory for everyone rather than you having to add custom code to support it. Otherwise, why is your project special that it needs a directory that is not standardized, and can you fully justify why the existing directories are insufficient for your needs? That said, commit a19743141 shows the addition of --runstatedir, as once such example of a globally-useful directory worth supporting, in response to GNU Coding Standards adding a variable for this directory in reaction to many distros preferring /run over /var/run when installing into /. And, I'm woefully low on free time, as that commit has not yet appeared in a released version of autoconf (2.69 predates it, and I really need to get 2.70 out the door). And, more generally, is there a way to make a configure script accept arguments that have a shape different from --with, --without, --enable and --disalbe? No, not without going against the GNU Coding Standards, which state that a configure script shouldn't need any other option prefixes. Again, what is the exact semantics you are hoping to add, and why are the existing mechanisms inappropriate for those semantics? A strong justification is needed, at which point maybe we can work on amending the GNU Coding Standards to document your use case for everyone to be able to share it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: non standard name of a dependency
On 9/21/18 2:44 PM, Catonano wrote:
I don't know if this is the right place to ask. If it's not, I apologize
I'd like to build guile-commonmark (
https://github.com/OrangeShark/guile-commonmark/ ) on Fedora 28
I'd like to build it against guile 2.2.2
On Fedora 28 x86_64 there are 2 versions of Guile
Guile 2.0.14
and
Guile 2.2.2
Guile 2.0.14 is in /usr/bin/guile
Guile 2.2.2 is in /usr/bin/guile2.2
this is what happens
...
configure: checking for guile 2.2
configure: found guile 2.2
What does config.log say it actually found?
checking for guile... /usr/bin/guile
Wait? Why is configure checking twice? You'll need to investigate what
the configure.ac for guile-commonmark is using, and why it is repeating
two different checks for guile (one that found the right version,
another that found the wrong one). If that code in configure.ac uses a
cache variable (${prefix}_cv_$...) and/or an environment variable
(probably $GUILE) to encode the result of the guile binary, then the
immediate workaround is to set that cache or environment variable as an
argument to configure, so that when it gets to that particular check, it
already has the answer you told it to use instead of the one it guesses
from your environment. If their configure.ac used
AC_CHECK_PROGS([guile]), then both of these should work:
./configure GUILE=/usr/bin/guile2.2
./configure ac_cv_prog_guile=/usr/bin/guile2.2
You'll also want to file a bug report to the guile-commonmark package
maintainers to have them improve their configure.ac if it isn't already
easily overridable.
configure: error: found development files for Guile 2.2, but /usr/bin/guile
has effective version 2.0
I'm afraid of removing guile 2.0.14 because it seems that an awful lot of
stuff depends on it
No, you shouldn't need to remove it.
How can I build guile-commonmark against guile 2.2.2 ?
Is this a task for the package author ?
Autoconf recommends using cache variables (for overriding decisions that
are otherwise guessed incorrectly from probing the system) and
envrionment variables (for pointing to a specific version of a tool that
you want to use), so this list is the appropriate place to ask about how
those things work in general. However, whether those things were
actually used correctly for the package in question is something for the
package author to answer, according to their configure.ac, which
autoconf does not maintain (although the package maintainer should feel
free to continue this thread if they need help improving their
configure.ac to match recommended best practices).
Or can I instruct the build system somehow about which guile to use ?
Yes, that should be possible if the package followed the autoconf
recommendations for allowing overrides.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: automatically showing test-suite.log on failure?
[adding autoconf, as this also affects testsuite.log generated by
projects using autotest instead of automake's built-in support]
On 9/21/18 12:37 PM, Bob Proulx wrote:
Bob Friesenhahn wrote:
Karl Berry wrote:
However, this seems like it would be fairly commonly useful and easy
enough to do in the canonical test-driver script. So, any chance of
adding it as a standard feature? Any reasonable way of enabling it would
be fine, e.g., a flag that can be added to [AM_]LOG_DRIVER_FLAGS.
Take care since some test logs could be megabytes in size.
I want to put a point in that often users try to be helpful and email
that multi-megabyte log file as an email attachment to bug reporting
mailing lists that sometimes have a lot of subscribers. This is very
painful on the network bandwidth usage. And also every downstream
subscriber, perhaps on a metered cell modem data plan, pays the cost
of receiving it whether they can help with it or not.
If there is some way, clever or not, to encourange the user to
compress that log file before attaching it that would save a lot of
downstream pain. When compressed that log file is a small fraction of
the original size and rarely a problem.
Just mentioning it to keep it in the brain cache when thinking about
improvements here. :-)
Indeed - I almost wonder if it would be worth patching the sequences
that generate testsuite.log to automatically generate a compressed
version in parallel, and in the output when a test fails, mention that
the user may inspect testsuite.log but should email the compressed
testsuite.log.XYZ to the developer. Determining the best compression
program to recommend is interesting - if the user is testing a package
that shipped only as foo.tar.xz, then testsuite.log.xz makes the most
sense to generate; but if foo ships both foo.tar.gz and foo.tar.xz, it
is not obvious which form the user uncompressed and would require a
configure or runtime probe for which compression engine to attempt.
If nothing else, autoconf should be patched where it states:
echo
if $at_debug_p; then
at_msg='per-test log files'
else
at_msg="\`${at_testdir+${at_testdir}/}$as_me.log'"
fi
AS_ECHO(["Please send $at_msg and all information you think might help:
in lib/autotest/general.m4, to mention the recommendation for compression.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Skip all version checks with autoconf?
On 08/24/2018 05:59 PM, Jeffrey Walton wrote: It is not autoconf's problem when someone writes a configure.ac that wrongly claims to use too-new of a version of automake. But if you don't think the package is actually relying on a feature that only that newer automake provided, you are welcome to edit configure.ac and change the AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf, and see if it completes successfully. OK, let's get rid of these useless checks whose only purpose is to stop someone from accomplishing their task at hand. sed -i '/AM_INIT_AUTOMAKE/d' configure.ac Nope, that's not how you do it. You NEED the AM_INIT_AUTOMAKE() line, just not necessarily the higher version number requirement within the line. I'm thinking more along the lines of: sed -i '/AM_INIT_AUTOMAKE/ s/\b[0-9.]*\b//' Or, actually install newer versions of the autotools. Lol... That put milk up my nose. I've tried to install newer versions and they have never worked right. The admins on the GCC compile farm tried the same and the shit does not work right. Claiming someone can upgrade these tools is a joke. Insulting the tools and/or the people that are trying to help you resolve your issues isn't going to resolve the issue. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Skip all version checks with autoconf?
On 08/24/2018 04:55 PM, Jeffrey Walton wrote: I'm catching this error on Fedora 28, x86_64, fully patched: $ autoreconf -fi configure.ac:35: error: require Automake 1.16.1, but have 1.15.1 autoreconf: automake failed with exit status: 1 You'll need to ask whatever project you are trying to build what feature from automake 1.16 they actually require, or whether they can relax their autoconf.ac to list a lower version number in their AM_INIT_AUTOMAKE() invocation. This is a chronic problem with Autotools. Nearly every program that gets patched has a problem like this. I no longer want to perform version checks. I waste too much time dicking around with the problems they cause. It is not autoconf's problem when someone writes a configure.ac that wrongly claims to use too-new of a version of automake. But if you don't think the package is actually relying on a feature that only that newer automake provided, you are welcome to edit configure.ac and change the AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf, and see if it completes successfully. I'm happy to take a break later in the process. I think I have more hope of fixing the actual problem if it is encountered. How do I skip all version checks? There's no magic environment variable to skip version checks built into autoreconf, but as with all open source, you are welcome to edit the source code at fault (the project's configure.ac) to comment out that project's particular version check. Or, actually install newer versions of the autotools. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to write directly to config.h from configure?
On 07/26/2018 10:36 AM, Jeffrey Walton wrote: Hi Everyone, I have a bad interaction with a project and Autotools. The project is not an Autotools project but we are trying to [cleanly] support Autotools. The project provides its own config.h since the mid-1990's. We want to supply roughly the same file though Autotools. The problem is, the project's config.h has some stuff that does not seem to fit in the Autotools model like typedefs and declarations of namespaces. I think the solution is to write directly to config.h but I can't figure out how to do it. Testing code like below is lost (i.e., it is not in the resulting config.h): ## Some real autoconf tests... cat << EOT >> config.h typedef unsigned char byte; typedef unsigned short word16; typedef unsigned int word32; EOT ## Back to real autoconf tests... Is it possible to write directly to config.h? If yes, then how do I do it? Sort of. It's possible to use AH_VERBATIM() to put almost-arbitrary text into the config.h file, with the caveat that '#undef' within that text is still a magic sequence that gets turned into a comment or #define as needed. For example, from autoconf itself: AC_DEFUN([AC_C_BIGENDIAN], [AH_VERBATIM([WORDS_BIGENDIAN], [/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel). */ #if defined AC_APPLE_UNIVERSAL_BUILD # if defined __BIG_ENDIAN__ # define WORDS_BIGENDIAN 1 # endif #else # ifndef WORDS_BIGENDIAN # undef WORDS_BIGENDIAN # endif #endif])dnl AC_CACHE_CHECK([whether byte ordering is bigendian], [ac_cv_c_bigendian], ... which results in a verbatim chunk of code in config.h where only one line (third from the bottom) is later rewritten by AC_DEFINE, but where the logic flow of the preprocessor doesn't care about the rewritten line on Apple universal builds. In your case, it looks like you'd do: AH_VERBATIM([MY_TYPEDEFS], [[ typedef unsigned char byte; typedef unsigned short word16; typedef unsigned int word32; ]]) (where MY_TYPEDEFS is replaced by whatever name you desire, although it should be prefixed to your project to avoid collisions) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: config.status: error: cannot find input file: ` .in'
On 07/01/2018 10:13 PM, John Calcote wrote: On Sun, Jul 1, 2018, 2:54 PM Sascha Manns wrote: [ 22s] checking that generated files are newer than configure... done [ 22s] configure: creating ./config.status [ 22s] config.status: error: cannot find input file: ` .in' Is that space literally part of the error message? Or is email garbling the spacing? This error is coming from the AC_CONFIG_FILES line. You seem to be specifying both the input and output files for some of the entries but not for all of them. You may do this but your syntax is incorrect. Start by removing all of the lines in the macro argument that end in .in. Well, most of them. But po/Makefile.in is actually a typical AC_CONFIG_FILES target, as gettext ships a po/Makefile.in.in (yes, with the double suffix), and does it's own thing later on during make to convert po/Makefile.in into an actual Makefile without having to depend on automake (although typically you don't store either po/Makefile.in.in nor po/Makefile.in in version control, as they are generated files). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure[xxxx]: : is not an identifer
e error message about an empty variable name being an invalid assignment might be a case of splitting right before the =). Any thought as to whether I should I just move along and recognize I need to use BASH in these cases, or is this an indication of something to address somewhere in the tool chain that does not detect this problem? Knowing that bash is a workaround is good; so now it's a question of whether it's also worth trying to spend effort on making autoconf smarter to avoid this problem with /bin/sh for other users of your platform, or whether your situation is niche enough that we just let you live with the workaround. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: configure[xxxx]: : is not an identifer
On 06/07/2018 02:17 PM, Kevin R. Bulgrien wrote:
I find myself trying to build newer versions of GNU toolchain components on a
very
old system, namely OpenServer 5.0.7. I know that supporting old systems like
this
is difficult, so I do recognize a need to do the heavy lifting on my own,
however,
if anyone could offer some help, it would be great.
I've run into the following error all too frequently, and, to avoid the error,
so
far, have just backed off to an older release of whatever is being built. For
example:
[kevinb@sddemokb:~/gnu.org/m4-1.4.18]$ ./configure -C --prefix=${HOME}
./configure[1845]: : is not an identifier
Can you run under '/bin/sh -x ./configure' (or whatever shell configure
actually picks in place of /bin/sh) to get a more verbose log right
before the failure message of what the script was attempting?
I supposed that perhaps in this case, [1845] might be a line number.
Or maybe a process id?
If that is the
case, I suppose that this error is happening in an ac_subst_vars='' assignment.
This assignment begins at line 630 and ends at line 1844 of the configure
script.
Line 1845 contains a different, one-line assignment: ac_subst_files=''
If it is not a line number, then knowing what the shell was executing
right beforehand might pinpoint where the error is. I'm suspecting that
somewhere in the script is an instance of ':=xyz', and the shell is
trying to interpret it as a variable assignment, except that ':' isn't a
variable name; that may have happened if something that was supposed to
substitute in a valid name instead ended up substituting in an empty string.
It's also possible to hack in echo statements (either to the
configure.ac, followed by regeneration, or directly into the generated
configure) to follow along as the script executes (sometimes, reaching,
or failing to reach, a 'Got here' message can be great for zeroing in on
where the problem is actually happening). Or even turn on 'set -x'
closer to the problem point, rather than running the entire script under
-x, for less verbose hunting for the problem.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: using autoconf to create build scripts for Assembly language programs
On 06/07/2018 11:23 AM, mallapadi niranjan wrote: Thanks for the reply, that did help a bit but was not able to remove the -c option I passed./configure CCAS=/usr/bin/as CFLAGS='' [ashok@mydevel foobar]$ make make all-am make[1]: Entering directory `/home/ashok/practice/ia32/myasm/autotools/foobar' /usr/bin/as --gstabs+ -c -o hello.o hello.s The automake documentation states that when you use AM_PROG_AS, your assembler MUST behave like a C compiler, in that it MUST accept -c and -o. If /usr/bin/as does not accept -c, then you'll have to provide a shell-script wrapper that adds that functionality on top of /usr/bin/as, at least according to the automake documentation. But again, the autoconf list is not the best list to be asking this; you'll (hopefully) get better response on the automake list, since it is an automake feature you are trying to use. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: using autoconf to create build scripts for Assembly language programs
On 06/07/2018 12:45 AM, mallapadi niranjan wrote: Greetings, i am newbie trying to learn autoconf, I would like to autoconf to have build scripts created to compile assembly language programs written using GNU Assembler: This is probably more a question for the automake list, since... Below are my configurations configure:ac AC_INIT([hello], [0.01]]) AC_CONFIG_SRCDIR([hello.s]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_AUX_DIR([build-aux]) AM_INIT_AUTOMAKE([-Wall -Werror]) AC_CONFIG_FILES([Makefile]) AM_PROG_AS ...AM_PROG_AS is an automake macro, and... AC_OUTPUT Makefile.am bin_PROGRAMS = hello hello_SOURCES = hello.s AM_CCAS = /usr/bin/as AM_CCASFLAGS = --gstabs+ ...AM_CCAS is a variable for use by automake, not autoconf. [ashok@mydevel foobar]$ make make all-am make[1]: Entering directory `/home/ashok/practice/ia32/myasm/autotools/foobar' gcc -g -O2 -o hello hello.o According to the automake manual, AM_CCAS sets $CCAS to a default of $CC unless you define it to something else. However, I have no idea why $AM_CCASFLAGS doesn't seem to be honored in this line; you'll have to ask the automake developers for help in debugging it. How do i override to use /usr/bin/as instead of gcc and pass -gstabs+ flag to /usr/bin/as. The easiest way there, per documentation (although I have not tested), is to run './configure CCAS=/usr/bin/as' to force configure to use your choice of assembler in place of the default (since the automake documentation said the default would be $CC which is typically gcc on a GNU/Linux system). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: sharedlocalstate default - does anybody use this?
On 06/06/2018 07:09 AM, Mariano, Adrian V. wrote: It has been brought to my attention that in my package (GNU units) I have a file that gets changed every day located in datarootdir---but this location is for read only files. The correct place for my architecture independent dynamic file would appear to be sharedstatedir. However, this resolves to the rather bizarre path /usr/local/com. I can't find any reference to anybody actually using this path. Do all the distributions over-ride this into something "normal"? Distros are not allowed to install into /usr/local. So a default of /usr/local/com is irrelevant to them - but still relevant to a non-distro build. The fedora units guy tells me it will be /var/lib, for example---and I think with redhat the whole /usr directory is supposed to be read only. Top-level /usr might be read-only, but distros don't control /usr/local. So what's the correct practice for my package? Should I use sharedstatedir and not worry about it resolving to a strange default path because mostly it will get changed by site defaults? Correct. Under the /usr/local hierarchy (when you install the software yourself as an add-on to the distro packaging), /usr/local/com is better than any other alternative, for still being located within a single hierarchy under your control. But under the /usr hierarchy (when the software is installed on your behalf by the distro), /var/lib is correct - but that's WHY './configure --sharedstatedir=/var/lib' exists, and distros are responsible for setting it. Or is there some other way to handle this? No, as long as you use sharedstatedir correctly, then you don't have to take care of anything further. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: why generate output to tmp file and mv to actual file?
On 06/01/2018 01:45 PM, John Calcote wrote: I recently ran across some sample code in section 19.4 of the Autoconf manual (modified slightly to reduce example): $(TESTSUITE): $(srcdir)/testsuite.at $(srcdir)/package.m4 autom4te --language=autotest -I '$(srcdir)' -o $@.tmp $@.at mv $@.tmp $@ This question isn't about autotest, but rather about the two commands in this rule - why generate the output into $@.tmp and then mv $@.tmp into $@? Is there some power mv has over autom4te that allows it better access to the target under some conditions? Atomicity. autom4te generates its output piecemeal (while it is running, you can see an incomplete version of $@.tmp); such an incomplete file will probably fail miserably but in an unpredictable manner when run as a shell script. As an example of the damage possible with an incomplete script? Suppose you are generating a shell script that states: rm -rf *.tmp but due to buffering constraints on stdio, the kernel happens to have flushed "rm -rf *" to disk (perhaps because it hit a 64k boundary, or so), but still has ".tmp" buffered up for a later write. In the common case, executing an incomplete script will hopefully cause a syntax error; but in cases like I just described, it can cause data loss. Thus, we generate into a temporary file (which no one will read in an intermediate state), then use mv to the final location (which has atomic semantics - anyone open()ing the file will see either the old inode which was presumably complete, or the new inode that we just completed), so that the target file is always a valid and complete file for reading or execution. In fact, the notion of generate to a temporary then move into place is a rather common idiom. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Problem with --version after compiling autoconf
On 05/30/2018 07:23 AM, Eric Blake wrote: which in turn is expanding this macro before calling m4's eval with invalid input: m4_bpatsubst(m4_bpatsubst(m4_translit(0,$1, [.-], [,,]),]dnl m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+], [+1,-1,[0r36:\&]]), [,0], [,[0r10:0]]) In fact, this used to work for single (but not multiple) letters; commit 6e1d6e2c (added in 2.63, Oct 2007) changed from a manual comparison of the three contiguous regions of a-z in EBCDIC into using m4's 0r36:NNN notation: -[m4_translit(m4_bpatsubsts(m4_tolower([[$1]]), - [\([0-9]+\)\([abcdefghi]\)], -[m4_eval(\1 + 1).-1.\2], - [\([0-9]+\)\([jklmnopqrs]\)], -[m4_eval(\1 + 1).-1.1\2], - [\([0-9]+\)\([tuvwxyz]\)], -[m4_eval(\1 + 1).-1.2\2]), -[abcdefghijklmnopqrstuvwxyz], -[12345678901234567890123456])]) +[m4_map_sep([m4_eval], [.], _$0([$1]))]) +m4_define([_m4_version_unletter], +[m4_translit(m4_bpatsubst([[[$1]]], ]dnl +m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+], + [+1.-1.[0r36:\&]]), So you've found a 10-year-old bug in autoconf, and an even older bug in m4. As least as far back as m4 commit bd11691d (Feb 2000, marked "Initial revision", which is when the current m4.git history starts), and the m4 1.4 release, m4's eval(0r36:NN) notation has been broken; more likely, all the way back to Nov 1993 when Francois Pinard introduced 0rNNN syntax into m4 1.1 (according to NEWS), although I cannot locate a tarball or version control of m4 that old. It's worth patching m4 to not botch large-radix numbers on EBCDIC, but it's also possible to patch autoconf to quit relying on large-radix numbers; I'll probably end up patching both projects, when I get a chance. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Problem with --version after compiling autoconf
On 05/30/2018 03:24 AM, Andy Armstrong wrote:
Hi Eric,
I ran 'make check' and got the following :
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib --language=autotest -I . -I . suite.at
-o ./testsuite.tmp
The command looks reasonable,
m4:local.at:18: bad expression in eval (bad input): ((?+1+0) > (2+0)) - ((?+1+0)
< (2+0))
autom4te: /workarea/tools/m4/bin/m4 failed with exit status: 1
but things are choking hard at:
m4_version_prereq([2.57])
which expands:
[m4_if(m4_version_compare(]m4_dquote(m4_defn([m4_PACKAGE_VERSION]))[, [$1]),
[-1],
[m4_default([$3],
[m4_fatal([Autoconf version $1 or higher is required],
[63])])],
[$2])]
which in turn is expanding this macro before calling m4's eval with
invalid input:
m4_bpatsubst(m4_bpatsubst(m4_translit(0,$1, [.-], [,,]),]dnl
m4_dquote(m4_dquote(m4_defn([m4_cr_Letters])))[[+],
[+1,-1,[0r36:\&]]), [,0], [,[0r10:0]])
What are the contents of lib/m4sugar/version.m4? But I suspect that
part is fine.
Actually, I'm now quite certain that the m4_bpatsubst is not properly
transliterating EBCDIC values into a base-36 number. And in fact,
looking at m4's source code, the problem is in m4 itself:
m4/src/eval.c:eval_lex()
/* FIXME - this calculation can overflow. Consider xstrtol. */
*val = 0;
for (; *eval_text; eval_text++)
{
if (isdigit (to_uchar (*eval_text)))
digit = *eval_text - '0';
else if (islower (to_uchar (*eval_text)))
digit = *eval_text - 'a' + 10;
else if (isupper (to_uchar (*eval_text)))
digit = *eval_text - 'A' + 10;
which means that anything larger than radix 20 (0-9 and a-j) is botched
on an EBCDIC machine.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: unable to escape ! in autotest stdout comparison text
On 05/29/2018 08:25 PM, John Calcote wrote:
I'm trying to create a test using autotest that compares the stdout of my
program with a string. Unfortunately, the output of the program contains
the path of the program. As part of its output, it writes its own program
name (from argv[0]) to stdout, so I have to use ${abs_top_builddir} as part
of the comparison text - which means I need to use AT_CHECK_UNQUOTED.
Another wrench in the works is that it then also adds an exclamation mark
(!) to the end of the line, so the stdout text I'm trying to compare with
ends with ! - when I run the test, the unquoting code appears to evaluate
the ! and remove the line (bash history feature, I think - there's nothing
in the history starting with my string, so it replaces the entire string
with nothing).
Yeah, bash's handling of ! can be quite a misfeature when you don't want
it to happen during scripting. But I thought it was disabled by default
in POSIX mode, which is what autotest scripts should be selecting, so
are you sure that history expansion is happening?
I've tried escaping with backslash, I've tried quoting with single quotes,
I've tried escaping within double quotes. Nothing works. It seems the
unquoting functionality will not be tricked into allowing a special
character to be escaped.
Any ideas?
Here's my testsuite.at:
AT_INIT
AT_SETUP([tg1])
AT_CHECK_UNQUOTED(["${abs_top_builddir}/src/prog"],,
[Hello from ${abs_top_builddir}/src/prog!])
AT_CLEANUP
First, are you sure you don't want a trailing newline? That is, did
src/prog output "!" as it's last character, or "\n" after the "!"? (The
placement of the ] in AT_CHECK[_UNQUOTED] matters).
I couldn't quickly reproduce the mangling of ! even though bash is my
shell and my /bin/sh, but I did reproduce failure using that
testsuite.at as you gave plus a minimal src/prog, configure.ac, and
Makefile.am for compiling and running the testsuite, due to the
difference in newlines. Once I fixed that, the test ran successfully.
To double-check, look at the generated testsuite, and show the code that
it is creating just before AT_STOP_1 (here's what I see with autoconf 2.69):
...
$as_echo "$at_srcdir/testsuite.at:3: \"\${abs_top_builddir}/src/prog\""
at_fn_check_prepare_notrace 'a ${...} parameter expansion' "testsuite.at:3"
( $at_check_trace; "${abs_top_builddir}/src/prog"
) >>"$at_stdout" 2>>"$at_stderr" 5>&-
at_status=$? at_failed=false
$at_check_filter
at_fn_diff_devnull "$at_stderr" || at_failed=:
echo >>"$at_stdout"; $as_echo "Hello from ${abs_top_builddir}/src/prog!
" | \
$at_diff - "$at_stdout" || at_failed=:
...
And $as_echo doesn't appear to be mangling ! for me, as long as I have
the right trailing newline.
But since the output is variable, perhaps the easiest thing is to
post-process the output prior to comparing it to fixed text, as in:
AT_INIT
AT_SETUP([tg1])
AT_CHECK_UNQUOTED(["${abs_top_builddir}/src/prog" |
sed "s|${abs_top_builddir}|DIR|"],,
[Hello from DIR/src/prog!
])
AT_CLEANUP
I'm open to using AT_CHECK also - but I haven't figured out a good way to
access my program without using the shell variables defined in atconfig.
My approach works with both AT_CHECK and AT_CHECK_UNQUOTED, as there is
no longer anything variable in the expected output. In fact, since bash
changes argv[0] into the absolute path when a PATH lookup was performed,
this also works:
AT_CHECK([PATH=$abs_top_builddir/src:$PATH; prog | sed ...] ...
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Problem with --version after compiling autoconf
On 05/29/2018 08:05 PM, Andy Armstrong wrote: The problem you see here is that the version reports as ?K??. Why could this be? My machine runs in the EBCDIC codepage and I am wondering if this could be associated. Very likely that this is related, if not the cause. However, I don't have access to an EBCDIC machine to debug things, so you'll probably have to do the debugging yourself. Is there a configure / make option I need to add. No, but then again, no one else has ever written this list stating that they are using autoconf on an EBCDIC machine. So there may be lots of things that need tweaking to work correctly. I suppose you could start by running 'make check', and then pasting the testsuite.log of the failing tests, if that might contain hints of where things are going wrong. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Does a 2.70 release exist?
On 04/24/2018 01:56 PM, Nicholas Clark wrote: > The catch is that I can't find Autoconf 2.70 anywhere! 2.69 seems like it's > the most recent release everywhere that I can find (except for the Git > repo). > > Where can I find the 2.70 release? Is GNU Make's documentation wrong and > 2.70 doesn't exist? If that's true, will it ever exist? I have not yet (made? found?) the time to release 2.70. But it will happen, someday. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [autoconf archive] syntax error in ax_lib_postgresql.m4 script.
On 03/22/2018 05:15 PM, Eric Blake wrote: Furthermore, you probably want to add: m4_pattern_forbid([AX_]) Make that m4_pattern_forbid([^AX_]) so that it is properly anchored to only flag words that begin with AX, rather than anywhere in the middle. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [autoconf archive] syntax error in ax_lib_postgresql.m4 script.
On 03/22/2018 04:51 PM, Jules Lamur wrote: Hello ! I encounter a syntax error while executing the AX_LIB_POSTGRESQL macro: ./configure: line 16962: syntax error near unexpected token `$POSTGRESQL_VERSION,ge,$postgresql_version_req,' ./configure: line 16962: ` AX_COMPARE_VERSION($POSTGRESQL_VERSION,ge,$postgresql_version_req, You reached the autoconf list, not the autoconf-archive list; but the AX_COMPARE_VERSION macro belongs to autoconf-archive. At first glance, it looks like your configure.ac attempted to call the AX_COMPARE_VERSION macro, but that you failed to provide any .m4 macro in any of the include directories searched by autoconf to actually expand that macro, so autoconf just blindly output the text from your configure.ac into the shell script instead of expanding it as desired. Usually, you should either copy the .m4 file containing the definition of AX_COMPARE_VERSION into your project, or else set up a -I /path/to/library where autoconf-archive macros reside, as part of your autoconf invocation processing your configure.ac file. Furthermore, you probably want to add: m4_pattern_forbid([AX_]) to your configure.ac, so autoconf can flag up front that it failed to expand the AX_COMPARE_VERSION macro as expected, rather than getting a cryptic shell error later on during the execution of ./configure about the syntax error at the point in the generated configure where the attempted macro was not expanded. I use this exact version of the script (which is the latest): https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_lib_postgresql.m4;h=e05dd17b7c8686323dcfa384c4408762630ae70b;hb=06a4043bea3ff31f81529fa78e5921aeadc986b5 Unfortunately, I don't have enough knowledge about autoconf to debug the issue, could someone help me to fix it? It's probably a question to the autoconf-archive list on their recommended practices for how to best install their .m4 files for use in your configure.ac file. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to change the shebang in 'configure' to require Bash
On 03/18/2018 10:39 AM, R. Diez wrote: I realise that this decision goes against Autoconf's portability principle. But even as a humble user, I am entitled to some freedom of choice. 8-) I could write some code in configure.ac to detect the current shell. But is there any way to tell Autoconf to output a Bash shebang in the generated 'configure' script, instead of the standard "#! /bin/sh". Not any easy way that I know of, precisely because it goes against autoconf's portability. If you're going to write in plain bash rather than a portable shell script, then do you need the additional layer of autoconf in the first place? I read about variable CONFIG_SHELL, but that looks like it's meant for the user. Or can I set that variable inside configure.ac? If you want to muck in the internals of autoconf, lib/m4sugar/m4sh.m4 emits the shebang lines during AS_INIT_GENERATED (for subsidiary scripts produced by the primary, such as config.status), and during AS_INIT (for the primary script, such as configure). Those macros are not set up to easily hook in a replacement, so you'd have to rewrite your m4 library to redefine those macros the way you want. If you think that other people would commonly want to hook in a different default shell than /bin/sh, you're welcome to turn it into a formal patch against autoconf instead of something you just override locally, but I'm not yet convinced that it is common to throw away portability. Please copy me on all the answers, as I am not subscribed to this mailing list. It's already list policy to reply-to-all, precisely for that reason. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: m4_map and AC_REQUIRE hoisting
etween O(n^3) and O(n^2) algorithms was very noticeable in time and memory consumed by 'autoconf'. > TEST2 > > Running this gives: > > def2 > hello > > as expected. > > I really have no idea why TEST1 results in a different expansion from > the other two examples. What exactly is different about m4_mapall? Hopefully my explanation into the deep magic guts helped! -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Should I define _GNU_SOURCE?
On 01/22/2018 09:55 AM, Victor Porton wrote: > I am writing a software for Linux/Unix which could benefit from > execvpe() C function. > > But this function is defined only when -D_GNU_SOURCE. > > Question 1: Should I ALWAYS use -D_GNU_SOURCE for compiler options no > matter what are user options? If you want to enable the use of a platform's extensions, the easiest way is to use the AC_USE_SYSTEM_EXTENSIONS macro (rather than -D_GNU_SOURCE, as that only works for a subset of systems), prior to the rest of your configure.ac that probes which extensions are now available. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to check for SIGABRT?
On 12/08/2017 02:36 PM, Simon Sobisch wrote: > We use the autoconf generated testsuite script in GnuCOBOL to test the > compiler and runtime - and it works very well for "normal" tests. > > There are some tests where the compiler should abort and it does, but > when it does so "correctly" by raising SIGABRT we can check for return > code 134 but get an additional stderr message similar to > "/full/path/to/testsuite.de/testcasenumber/run aborted on line 40" (and > I don't know if SIGABRT will result in return code 134 on all "exotic" > systems). POSIX says that SIGABRT is 6 on XSI systems, but you can be compliant with POSIX without being an XSI system (but non-XSI systems tend to not run autoconf). However, your bigger problem is that on ksh, SIGABRT shows up in $? as 262 (it specifically treats signals as 256+num instead of 128+num, to make signals unambiguous with normal exit status). > > The following options come to mind: > > * use `trap` in AT_CHECK to catch the error if it is the expected result > --> should fix the additional stderr, we still would have to check for > return code 134 Your trap could then exit (normally) with a known exit status, rather than reusing the inherited status that may or may not be 134. Or even write to a witness file, ignore the value of $? altogether, and do a second AT_CHECK that the witness file was touched. > Do you have any experience/thoughts about this? > Is there any "best practice" (ideally as official documentation) for > checking signals in the autoconf generated testsuite script? Expecting death to a signal is unusual, so I don't know of anyone else doing it. But if it is a common enough paradigm, I agree that making it easier in autotest to check that a process died due to a particular signal may be a worthwhile enhancement. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why my AT_CHECK() can't work?
On 08/17/2017 10:54 PM, Sam wrote:
> Could I use regular match in AT_CHECK? Like this:
Please don't top-post on technical lists; it makes it harder to follow
the conversation.
>
> m4_define([OVS_VSWITCHD_STOP],
>> [AT_CHECK([/etc/init.d/openvswitch stop], [0], [stdout], [])
>> AT_CHECK([[awk '/Killing ovsdb-server/' stdout | sed -e 's/[ ]*$//g']],
That's a lot of typing and a waste of a process. Why not just use the
shorter:
AT_CHECK([sed -n '/Killing ovsdb-server/ s/ *$//p' stdout],
(that is, using 'awk' as a longhand for 'grep' followed immediately by
piping through 'sed' is pointless, when you can do it all in 'sed'; and
using 'g' on a substitution anchored at the end of a line is pointless).
>> [0], [Killing ovsdb-server ([0-9]*)
AT_CHECK only does direct textual matches. But never fear - you can do
filtering as part of your command to pre-process the actual text into
something that will match your expected text - similar to how you are
eating trailing space, you can also convert random pids into a stable
placeholder, as in this example:
AT_CHECK([sed -n '/Killing ovsdb-server/ { s/ *$//; s/[0-9]*/PID/; p }'
stdout],
[0], [Killing ovsdb-server (PID)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why my AT_CHECK() can't work?
On 08/09/2017 09:56 PM, Sam wrote: > Yes, it's because a space at the end of line: > > --- -^I2017-08-10 10:51:06.097868811 +0800$ >> +++ > but in my match, I add a space, I don't know why it doesn't work. > > AT_CHECK([[awk '/ACTIVE/' stdout | head -4]], [0], [LACP actor_state ACTIVE >> AGGREGATION SYNC COLLECTING DISTRIBUTING $ >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING $ >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING $ >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING $ >> ])$ Because autoconf eats trailing spaces by default (it's a feature). You can work around it by TELLING autoconf that you intend for there to be trailing space: AT_CHECK(..., [[trailing space preserved here: @&t@ but not here more text]]) The @&t@ quadrigraph (mnemonic 'and-t' sounds similar to 'empty') expands to nothing, but is converted after the point when trailing whitespace is eaten. The manual documents this: https://www.gnu.org/software/autoconf/manual/autoconf.html#Quadrigraphs -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why my AT_CHECK() can't work?
On 08/09/2017 04:45 AM, Sam wrote: > Then I change commd into `awk '/ACTIVE/' stdout | head -4`, it failed > again, log is : > > ./netdev-dpdk.at:28: awk '/ACTIVE/' stdout | head -4 >> --- - 2017-08-09 17:41:24.809066088 +0800 >> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout >> 2017-08-09 17:41:24.807150522 +0800 >> @@ -1,5 +1,5 @@ >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING Could this be a difference in line endings between what your .at file used and what stdout contains (which in turn is what line endings ovs-appctl outputs)? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Why my AT_CHECK() can't work?
On 08/09/2017 04:15 AM, Sam wrote: > Hi all, > > I'm using autotest to test ovs, and I write a new *.at file using only one > AT_CHECK sentence like this: > > AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout]) >> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state Note - this invocation of sed will print EVERY line, as well as printing the lines that contain ACTIVE a second time. Also, 'head -4' is obsolete syntax that is not portable to all machines; 'sed -n4' is newer (and given your use of ovs-appctl, probably works on all machines that you care about). You probably meant to use [[sed -n '/ACTIVE/p' stdout | head -n4]] or even [[grep ACTIVE stdout | head -n4]] >> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]]) > >> ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4 >> --- - 2017-08-09 16:59:18.802810195 +0800 >> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout >> 2017-08-09 16:59:18.801176471 +0800 >> @@ -1,4 +1,5 @@ >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING >> + dpdkb2 >> +bond_mode: 4 >> + >> +slave 0: >> + >> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show ( >> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28) > > > 1. I don't know what "+" "-" means, and why there are "+" and "-"? That is the output of 'diff'. '-' lines are what you EXPECTED the output to contain, '+' lines are what the output ACTUALLY contained. > 2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head -4`, > result is: Notice that what you ran by hand limited the sed output to just the interesting lines, rather than the first four lines where lines containing ACTIVE were doubled. > That's exactly what I matched in AT_CHECK, why it fails? No, it's not exactly what you passed to AT_CHECK ;) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Determination of default configuration values for build projects and checking the settings
On 07/11/2017 05:43 AM, SF Markus Elfring wrote: > Hello, > > I find the following information interesting once more. > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Site-Defaults.html > “… > Autoconf-generated configure scripts allow your site to provide default values > for some configuration values. You do this by creating site- and system-wide > initialization files. > …” > > 1. Will it become possible to select such defaults only for specific software >build projects? Unless someone writes a patch to autoconf (and then you propagate the use of that new autoconf to all affected packages), it is only possible to select per-package defaults insofar as those packages stick to per-package cache variable names. > > 2. These values will be passed to configuration and make scripts. >How much do you trust that they are really usable? If you don't trust site-wide defaults, then don't install them. >If you would like to perform validation checks again, I am looking for ways >to avoid corresponding code repetition there. Site-wide defaults set cache variables in order to avoid repetitive testing; but if you don't trust the installed site-wide defaults that you get when you avoid the testing, then what DO you trust? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Variable expansin in AC_PREFIX_DEFAULT
On 03/22/2017 03:20 AM, Joakim Jalap wrote: > Hello autoconf gurus! > > I am trying to write some autotools support for installing a latex > package. On CTAN I found some autoconf macros (which I had to modify a > bit) which I use to find for example latex(1) and pdflatex(1). So far so > good. This CTAN package also has a macro to find the path to the tex > installation, AC_TEXMF_PATH. This finds the correct path for me at It's poor practice to name a macro in the AC_ namespace if it is not actually owned by autoconf; you may want to choose a different namespace to make it obvious where the macro originates from. > /usr/share/texmf-dist. Now I want to put this as the default prefix so > that configure will "do the right thing" by default, but this is where I > fail. > > This is my configure.ac: > > AC_INIT([package], [0.1], [blah]) > AC_PREREQ([2.60]) > AC_CONFIG_MACRO_DIR([m4]) > AM_INIT_AUTOMAKE([foreign]) > > AC_PROG_INSTALL > AC_PROG_LATEX > AC_PROG_KPSEWHICH > AC_PROG_PDFLATEX > AC_TEXMF_PATH > > AC_PREFIX_DEFAULT([$texmfpath]) > AC_MSG_NOTICE([$texmfpath]) > > AC_CONFIG_FILES(Makefile) > AC_OUTPUT > > AC_TEXMF_PATH exports `texmfpath' and does AC_SUBST on it. (You can find > all the macros here: https://www.ctan.org/tex-archive/support/autoconf) > > The problem is with the AC_PREFIX_DEFAULT. It sets the default prefix to > empty. But the AC_MSG_NOTICE macro on the line below prints the correct > path! So somehow $texmfpath is expanded to the correct value by > AC_MSG_NOTICE, but it is expanded to nothing on the line above. If I do > AC_PREFIX_DEFAULT(["some_path"]) then the default prefix is correctly > set to "some_path". Indeed, thanks to the magic of m4 diversions, AC_PREFIX_DEFAULT expands to code that appears very early in configure, and using a shell variable that early in the run is tricky; while AC_MSG_NOTICE expands to code that runs at the place where the macro was used. > > Is it not possible to set the default prefix in this way? What other > good ways are there to set the default prefix to something discovered at > configure time? Is AC_PREFIX_PROGRAM any better for your use case? > > I'm not subscribed to the list so if somebody answers, please keep me on > cc :) That's GNU list policy anyways. -- Eric Blake eblake 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: #ifndef BIGENDIAN #undef BIGENDIAN ?
On 02/26/2017 01:10 AM, Kai Noda wrote: > Hi all, > > I don't quite understand this piece of code: > > http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blobdiff;f=lib/autoconf/c.m4;h=51fdfeba68fffe7f6f5638eaeef00149ed168282;hp=ffaa06e39dff758a24618a8f6504b22103caefac;hb=b0e687ef42e21b1eb7af18c4eaebcd41b0bd5632;hpb=883c8994f1efdc3c550b0d37bf95c947881b735d > > #else > # ifndef WORDS_BIGENDIAN > # undef WORDS_BIGENDIAN > # endif This is the proper way to set up a config template. When config.status runs, ALL it does is replace '#undef' lines with either '/* #undef */' or '#define' lines, according to what was learned during configure. All other lines are left untouched. > > What was it supposed to achieve? Should it not be either of these two? > > #ifndef WORDS_BIGENDIAN > **#define** WORDS_BIGENDIAN This is what results in the final config.h based on the template on machines where the #define is needed. > > or > > **#ifdef** WORDS_BIGENDIAN > #undef WORDS_BIGENDIAN No, this is not what is wanted. > > Please disregard if I missed something elementary. I'm not literate in m4. It's not m4, but autoconf doing this. It's documented here: https://www.gnu.org/software/autoconf/manual/autoconf.html#Header-Templates > I just tried to use AC_C_BIGENDIAN for my project and was startled to > see its output. The output is correct. Remember that config.h.in files have a slightly different syntax than the final generated config.h file. -- Eric Blake eblake 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: Configure breaks by build
On 02/19/2017 02:48 PM, Sascha Manns wrote: > Hello list, > > i'm preparing some autotools files for my new project. > > I have in my configure.ac: > > GDK30_MINIMUM_VERSION=2.99.0 > GTK30_MINIMUM_VERSION=2.99.0 > ATK_MINIMUM_VERSION=2.99.0 > > PKG_CHECK_MODULES(gdk-3.0 >= $GDK30_MINIMUM_VERSION > gtk+-3.0 >= $GTK30_MINIMUM_VERSION > atk >= $ATK_MINIMUM_VERSION) The autoconf package does not maintain the PKG_CHECK_MODULES() macro, so your question is probably better asked on the pkg-config development list. However, it appears to me that you are getting an error because your usage of the macro is incorrect. Here's an example I picked up from a package that uses the macro correctly: PKG_CHECK_MODULES([LIBNL_ROUTE3], [libnl-route-3.0]) which makes it look like you forgot a first argument. -- Eric Blake eblake 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: Couldn't locate INSTALL file
On 02/07/2017 12:50 AM, Ying Chang wrote: > Hi, I am a biologist who doesn't know much about computers. I need to > install autoconf as it is one of the dependencies of a program that I want > to use. I downloaded the autoconf package with 'git clone git:// > git.sv.gnu.org/autoconf' . Building from git is NOT the recommended way to casually meet a prerequisite; git builds are intended primarily for development of autoconf itself, rather than using autoconf for other projects. The primary means of installing autoconf is by using a pre-built package (if you are using a distribution), or by using a tarball (ftp://ftp.gnu.org/gnu/autoconf/), where 2.69 is the latest release (although I'm hoping to release 2.70 soon). > The README file says that I should read BUGS and > INSTALL. But there is no INSTALL file in the package. INSTALL exists in the tarballs (it is created as part of bootstrapping the git checkouit). When building from git, you first have to bootstrap the package, at which point the directions in HACKING are relevant. But note that the directions in HACKING state that you cannot bootstrap autoconf from git unless you have _first_ installed autoconf from a tarball (or distribution) - so you're right back to needing that tarball. And if you are not planning on developing autoconf itself, then why bother with bootstrapping git? -- Eric Blake eblake 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: config.status and /bin/sh on Solaris
On 01/27/2017 01:11 PM, Dimitrios Apostolou wrote: > Where is the source for this shebang generation? Maybe I can make some > sense out of it. The #! line in config.status is _supposed_ to be the value of CONFIG_SHELL (whether inherited from the environment because you pre-set it, or because it was the value of the best candidate shell found during the initial startup of configure where it re-exec's itself into the best shell found). config.log may or may not be useful at determining this, because finding the right candidate shell is very early in the startup. But a trace of manually running '/path/to/shell -x ./configure' may help see what was probed (warning, the trace may be huge, so don't go blindly posting megabytes of stuff to this list). -- Eric Blake eblake 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: complex configure tests involving multiple files and possibly libtool/automake
On 01/26/2017 03:42 PM, Eric Blake wrote: > > I'm not directly aware of a way to do it, but you CAN use AC_TRY_COMPILE > and then in the 'action-if-true' branch you can copy conftest.o to a > safe location, then try and figure out how to make the subsequent > AC_TRY_LINK refer back to the .o file that you squirreled away. You'll > have to experiment if you can't find an actual example, and if you get > it working, be sure to post back to the list, but I hope that gives you > some hints of things to try. Correction - use the modern macros instead. In fact, AC_COMPILE_IFELSE already documents that you can access conftest.$OBJEXT in the action-if-true block, so it is a supported interface: https://www.gnu.org/software/autoconf/manual/autoconf.html#Running-the-Compiler -- Eric Blake eblake 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: complex configure tests involving multiple files and possibly libtool/automake
On 01/26/2017 02:35 AM, Václav Haisman wrote: > Hi. > > I have a test that I would like to run during configure time which > basically involves compiling two files and linking a shared object/DLL > out of them. I think I would like to be using automake/libtool to > compile and link the configure test itself. Is there a good practice > or good example on how to do this? I'm not directly aware of a way to do it, but you CAN use AC_TRY_COMPILE and then in the 'action-if-true' branch you can copy conftest.o to a safe location, then try and figure out how to make the subsequent AC_TRY_LINK refer back to the .o file that you squirreled away. You'll have to experiment if you can't find an actual example, and if you get it working, be sure to post back to the list, but I hope that gives you some hints of things to try. > > Before you comment, no, simple single file compile and link will not > do. This is in attempt to detect issue on Cygwin with C++11 > `thread_local`. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#. > -- Eric Blake eblake 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: Defining data files to install
On 01/26/2017 03:22 PM, Julie Marchant wrote: > Hi, > > I'm a little confused about how to set up Autoconf to install data files > for the program to use later, and I wondered if someone can clear up my > confusion. > > For reference, the pertinent program is Project: Starfighter: > > http://starfighter.nongnu.org > > Starfighter has a few different directories with required data files: > "data", "gfx", "music", and "sound". All files in these directories need > to be installed to a location that gets defined as DATADIR. From what I > understand so far, the directory I want to use is the one stored in the > pkgdatadir variable, and I include files to install there by assigning > them in a Makefile.am to pkgdata_DATA. But listing the files out from a > Makefile.am in the same directory doesn't copy the directory structure, > and if I indicate a directory from the top-level Makefile.am, "make > install" just ignores (or rather, "omits") it and then spits out an > error with no accompanying information. Makefile.am is read by automake, so your question is more likely to be answered in the automake manual than the autoconf manual. > > What am I missing here? How can I install these data files not into the > top-level pkgdatadir, but in the respective appropriate sub-directories > of pkgdatadir (e.g. "$(pkgdatadir)/data" and "$(pkgdatadir)/music")? I > can't find any documentation on how to do this anywhere. Automake lets you define new targets that are subdirectories. In fact, a quick search for $(pkgdatadir) found an example that might be pertinent to your use case: https://www.gnu.org/software/automake/manual/automake.html#Alternative But I'm not as good at automake as I am at autoconf, so I'm cc'ing that list in, in case someone else has more ideas. -- Eric Blake eblake 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: AC_SYS_LARGEFILE documentation misleading
On 01/25/2017 11:30 AM, Thorsten Glaser wrote:
> On Wed, 25 Jan 2017, Eric Blake wrote:
>
>> Please propose a patch to the documentation, rather than just telling me
>> that it is wrong, so that we have a concrete proposal for a wording
>> improvement that we can discuss.
> Oh okay, I’ll cater for lazy upstreams this time ;-)
It's not necessarily laziness :)
> See the attached git format-patch.
>
Thanks; that's helpful. I'm still thinking we may want to iterate on
the wording, in particular:
> +++ b/doc/autoconf.texi
> @@ -8584,8 +8584,8 @@ if the system supports @samp{#!}, @samp{no} if not.
> Arrange for 64-bit file offsets, known as
> @uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
> large-file support}. On some hosts, one must use special compiler
> -options to build programs that can access large files. Append any such
> -options to the output variable @code{CC}. Define
You're deleting all mention that the macro may modify CC (true, it
doesn't do it on most platforms, but the code is still there that does
it for Irix); I don't think we want the change to be that drastic.
> +options to build programs that can access large files. Define,
> +by calling @code{AC_DEFINE_UNQUOTED},
> @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
I also think we can try harder to point out the need for config.h to
appear first. How about the following counter-proposal:
diff --git i/doc/autoconf.texi w/doc/autoconf.texi
index 55f96a3..2901937 100644
--- i/doc/autoconf.texi
+++ w/doc/autoconf.texi
@@ -8584,9 +8584,10 @@ System Services
Arrange for 64-bit file offsets, known as
@uref{http://@/www.unix-systems@/.org/@/version2/@/whatsnew/@/lfs20mar.html,
large-file support}. On some hosts, one must use special compiler
-options to build programs that can access large files. Define,
-by calling @code{AC_DEFINE_UNQUOTED},
-@code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if necessary.
+options to build programs that can access large files, and this macro
+modifies the output variable @code{CC} in that case. This macro will
+additionally define @code{_FILE_OFFSET_BITS} and @code{_LARGE_FILES} if
+necessary, by calling @code{AC_DEFINE_UNQUOTED}.
Large-file support can be disabled by configuring with the
@option{--disable-largefile} option.
@@ -8595,7 +8596,9 @@ System Services
@code{off_t} is wider than @code{long int}, since this is common when
large-file support is enabled. For example, it is not correct to print
an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.
+(long int) X)}. Also, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
+before any system header.
The LFS introduced the @code{fseeko} and @code{ftello} functions to
replace their C counterparts @code{fseek} and @code{ftell} that do not
--
Eric Blake eblake 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: AC_SYS_LARGEFILE should output to CPPFLAGS
On 01/25/2017 10:57 AM, Thorsten Glaser wrote: > On Wed, 25 Jan 2017, Thorsten Glaser wrote: > >> Looking at the source, AC_SYS_LARGEFILE calls AC_DEFINE_UNQUOTED, >> which appends to DEFS (which I agree with Tom Dickey is wrong) as >> Florian Weimer said, but — even more confusingly — only when >> AC_CONFIG_HEADERS is not used. >> >> If AC_CONFIG_HEADERS is used, the definition is only written to >> its output file (config.h by default). >> >> This is even more unfortunate, because now, if any program includes >> a glibc system header before "config.h", the definition will be >> ignored, because it comes too late. >> >> CPPFLAGS is r̲e̲a̲l̲l̲y̲ the correct place for this. Again. > > Let’s keep track of t̲h̲i̲s̲ bug here <852...@bugs.debian.org>. > Again, please forward this upstream, too. > > The workaround I was forced to use in a real-world package is thus: > https://anonscm.debian.org/cgit/pkg-remote/xrdp.git/plain/debian/patches/lfs.diff?id=e17430063641d44f5596b5bfc1b32ac4ba39f9f1 If the real-world package is not including config.h first, then that is a bug in the real-world package that should be fixed there. Autoconf clearly documents that if you create config.h, it MUST be included first, before any system headers. -- Eric Blake eblake 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: AC_SYS_LARGEFILE documentation misleading
On 01/25/2017 10:45 AM, Thorsten Glaser wrote: > > This is even more unfortunate, because now, if any program includes > a glibc system header before "config.h", the definition will be > ignored, because it comes too late. This is wrong. The manual clearly states that config.h MUST be included prior to any system headers, precisely because config.h can influence what system headers do. In fact, gnulib offers a 'make syntax-check' that, among other things, enforces that a project ALWAYS includes config.h first. > But that’s a different bug. This issue is about the documentation > being wrong — please fix the documentation and raise this bug upstream > (and this time, don’t let them tell you it’s not a bug because it most > curtainly is). Please propose a patch to the documentation, rather than just telling me that it is wrong, so that we have a concrete proposal for a wording improvement that we can discuss. -- Eric Blake eblake 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: Compile-Run Cycle
On 12/27/2016 09:30 PM, Anarchean wrote: > > I use two terminals, one is running vim from inside the > src dir. The other one has a variable PREFIX=$project_root/sandbox, > and I use it to compile and run the program, which is usually the > follow command sequence: > > Once in a while: > % ./configure --prefix="$PREFIX" > > And then every modification: > % make > % make install > % "$PREFIX/bin/project_name" > > Is there any way to automate this? How people usually do it? That works. Another thing to try is to get your software to the point that it will run when uninstalled, from a VPATH build tree. Then you can shorten the steps to % make % ./src/project_name assuming that the 'make install' step is what copies src/project_name to $PREFIX/bin/project_name. If you have a good testsuite, and have properly hooked it into automake, then 'make check' is a good way to test the uninstalled project. -- Eric Blake eblake 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: [PATCH] autoheader: check templates of all config headers
On 12/21/2016 10:15 AM, Daniel Elstner wrote: > Hi, > > sorry for taking so long to get back to this. But I see a release is > imminent, so I figured better late than never. Thank you so much for reposting! My perl is not as strong as I would like, but your patch was at least legible to me (perl makes it easier to do worse), and the idea makes sense. The testsuite addition was a clincher. I'm going ahead and applying this, once it passes 'make check' (currently in progress on my machine). -- Eric Blake eblake 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: Timeline for 2.70 (hit issue fixed in e17a30e9)
On 12/18/2016 09:22 PM, Andrei Borzenkov wrote: > We got report that GRUB build fails under glibc 2.25 due to issue fixed > in commit e17a30e9 (warnings about using major() etc from sys/types.h > with -Werror). It was confirmed that this commit fixes the problem. This > means we effectively need to mark minimal required autoconf version as > 2.70 and so should delay next release until it. What are plans for > release of 2.70? Thank you! My hope is to get a release done before the end of the year, but that is fast approaching. -- Eric Blake eblake 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
[PATCH 1/2] mountlist: include sysmacros.h for glibc
On Fedora rawhide (glibc 2.25), './gnulib-tool --test mountlist' reports: ../../gllib/mountlist.c: In function 'read_file_system_list': ../../gllib/mountlist.c:534:13: warning: '__makedev_from_sys_types' is deprecated: In the GNU C Library, `makedev' is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use `makedev', include directly. If you did not intend to use a system-defined macro `makedev', you should #undef it after including . [-Wdeprecated-declarations] me->me_dev = makedev (devmaj, devmin); ^~ In file included from /usr/include/features.h:397:0, from /usr/include/sys/types.h:25, from ./sys/types.h:28, from ../../gllib/mountlist.h:23, from ../../gllib/mountlist.c:20: /usr/include/sys/sysmacros.h:89:1: note: declared here __SYSMACROS_DEFINE_MAKEDEV (__SYSMACROS_FST_IMPL_TEMPL) ^ Fix it by including the right headers. We also need a fix to autoconf's AC_HEADER_MAJOR, but that's a separate patch. * m4/mountlist.m4 (gl_PREREQ_MOUTLIST_EXTRA): Include AC_HEADER_MAJOR. * lib/mountlist.c (includes): Use correct headers. Signed-off-by: Eric Blake --- ChangeLog | 7 +++ lib/mountlist.c | 6 ++ m4/mountlist.m4 | 3 ++- 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index a936166..ae0816d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2016-09-14 Eric Blake + + mountlist: include sysmacros.h for glibc + * m4/mountlist.m4 (gl_PREREQ_MOUTLIST_EXTRA): Include + AC_HEADER_MAJOR. + * lib/mountlist.c (includes): Use correct headers. + 2016-09-13 Paul Eggert intprops: new macro TYPE_WIDTH diff --git a/lib/mountlist.c b/lib/mountlist.c index bb4e4ee..cf4020e 100644 --- a/lib/mountlist.c +++ b/lib/mountlist.c @@ -37,6 +37,12 @@ # include #endif +#if MAJOR_IN_MKDEV +# include +#elif MAJOR_IN_SYSMACROS +# include +#endif + #if defined MOUNTED_GETFSSTAT /* OSF_1 and Darwin1.3.x */ # if HAVE_SYS_UCRED_H # include /* needed on OSF V4.0 for definition of NGROUPS, diff --git a/m4/mountlist.m4 b/m4/mountlist.m4 index 2e2ca37..b6724fa 100644 --- a/m4/mountlist.m4 +++ b/m4/mountlist.m4 @@ -1,4 +1,4 @@ -# serial 11 +# serial 12 dnl Copyright (C) 2002-2006, 2009-2016 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -15,5 +15,6 @@ AC_DEFUN([gl_PREREQ_MOUNTLIST_EXTRA], [ dnl Note gl_LIST_MOUNTED_FILE_SYSTEMS checks for mntent.h, not sys/mntent.h. AC_CHECK_HEADERS([sys/mntent.h]) + AC_HEADER_MAJOR()dnl for use of makedev () gl_FSTYPENAME ]) -- 2.7.4 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
[PATCH 2/2] sys_types: avoid glibc 2.25 warnings about major()
Todo: tweak sys_types_h.m4 comment before pushing
glibc 2.25 is deprecating the namespace pollution of
injecting major(), minor(), and makedev() into the compilation
environment, with a warning that insists that users include
instead. However, because the expansion of
AC_HEADER_MAJOR didn't bother checking sys/sysmacros.h until
after probing whether sys/types.h pollutes the namespace, it was
not defining MAJOR_IN_SYSMACROS, with the result that code
compiled with -Werror chokes on the deprecation warnings because
it was not including sysmacros.h.
Backport the autoconf fix, so that gnulib projects avoid the
warnings even when using older autoconf.
* m4/sys_types_h.m4 (AC_HEADER_MAJOR): Replace broken version in
older autoconf.
* doc/posix-headers/sys_types.texi (sys/types.h): Document fix.
* doc/glibc-functions/gnu_dev_major.texi (gnu_dev_major): Likewise.
* doc/glibc-functions/gnu_dev_makedev.texi (gnu_dev_makedev): Likewise.
* doc/glibc-functions/gnu_dev_minor.texi (gnu_dev_minor): Likewise.
Signed-off-by: Eric Blake
---
Obviously, I'll be tweaking this slightly to list an actual
commit id that gets pushed to autoconf, but posting now for
review.
ChangeLog| 8
doc/glibc-functions/gnu_dev_major.texi | 4
doc/glibc-functions/gnu_dev_makedev.texi | 4
doc/glibc-functions/gnu_dev_minor.texi | 4
doc/posix-headers/sys_types.texi | 6 ++
m4/sys_types_h.m4| 27 ++-
6 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index ae0816d..1e694e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2016-09-14 Eric Blake
+ sys_types: avoid glibc 2.25 warnings about major()
+ * m4/sys_types_h.m4 (AC_HEADER_MAJOR): Replace broken version in
+ older autoconf.
+ * doc/posix-headers/sys_types.texi (sys/types.h): Document fix.
+ * doc/glibc-functions/gnu_dev_major.texi (gnu_dev_major): Likewise.
+ * doc/glibc-functions/gnu_dev_makedev.texi (gnu_dev_makedev): Likewise.
+ * doc/glibc-functions/gnu_dev_minor.texi (gnu_dev_minor): Likewise.
+
mountlist: include sysmacros.h for glibc
* m4/mountlist.m4 (gl_PREREQ_MOUTLIST_EXTRA): Include
AC_HEADER_MAJOR.
diff --git a/doc/glibc-functions/gnu_dev_major.texi
b/doc/glibc-functions/gnu_dev_major.texi
index f7a2cfd..3a85300 100644
--- a/doc/glibc-functions/gnu_dev_major.texi
+++ b/doc/glibc-functions/gnu_dev_major.texi
@@ -6,6 +6,10 @@ gnu_dev_major
Portability problems fixed by Gnulib:
@itemize
+The @code{AC_HEADER_MAJOR} macro in Autoconf 2.69 and earlier fails to
+set @code{MAJOR_IN_SYSMACROS} when it detects namespace pollution in
+@file{sys/types.h}; which in turn provokes deprecation warnings in
+glibc 2.25.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/glibc-functions/gnu_dev_makedev.texi
b/doc/glibc-functions/gnu_dev_makedev.texi
index febd7f8..2738698 100644
--- a/doc/glibc-functions/gnu_dev_makedev.texi
+++ b/doc/glibc-functions/gnu_dev_makedev.texi
@@ -6,6 +6,10 @@ gnu_dev_makedev
Portability problems fixed by Gnulib:
@itemize
+The @code{AC_HEADER_MAJOR} macro in Autoconf 2.69 and earlier fails to
+set @code{MAJOR_IN_SYSMACROS} when it detects namespace pollution in
+@file{sys/types.h}; which in turn provokes deprecation warnings in
+glibc 2.25.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/glibc-functions/gnu_dev_minor.texi
b/doc/glibc-functions/gnu_dev_minor.texi
index a3dbefe..b4c789c 100644
--- a/doc/glibc-functions/gnu_dev_minor.texi
+++ b/doc/glibc-functions/gnu_dev_minor.texi
@@ -6,6 +6,10 @@ gnu_dev_minor
Portability problems fixed by Gnulib:
@itemize
+The @code{AC_HEADER_MAJOR} macro in Autoconf 2.69 and earlier fails to
+set @code{MAJOR_IN_SYSMACROS} when it detects namespace pollution in
+@file{sys/types.h}; which in turn provokes deprecation warnings in
+glibc 2.25.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/doc/posix-headers/sys_types.texi b/doc/posix-headers/sys_types.texi
index 29bb9ae..cf44bea 100644
--- a/doc/posix-headers/sys_types.texi
+++ b/doc/posix-headers/sys_types.texi
@@ -19,6 +19,12 @@ sys/types.h
@item
The type @code{mode_t} is not defined on some platforms:
MSVC 9.
+@item
+Some systems leak definitions of @code{major}, @code{minor}, and
+@code{makedev} through this header; however, when
+@file{sys/sysmacros.h} exists, that file should also be included to
+avoid deprecation warnings from the versions in this header:
+glibc 2.25.
@end itemize
Portability problems not fixed by Gnulib:
diff --git a/m4/sys_types_h.m4 b/m4/sys_types_h.m4
index b0aabb4..64be679 100644
--- a/m4/sys_types_h.m4
+++ b/m4/sys_types_h.m4
@@ -1,4 +1,4 @@
-# sys_types_h.m4 serial 5
+# sys_types_h.m4 serial 6
dnl Copyright (C) 2011-2016 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
[gnulib PATCH 0/2] Work around glibc 2.25 deprecation warnings
Fedora rawhide builds of libvirt.git at commit d53fa838^ failed due to the new glibc 2.25 deprecation warning for use of major() from just ; I also found that the same warning is provoked by gnulib's mountlist module. Libvirt commit d53fa838 was a temporary hack to work around the problem, and I will be reverting that and updating to newer gnulib once this goes in. I've tested that libvirt on Fedora rawhide with d53fa838 reverted and gnulib updated to this commit was once again able to build. Comments welcome, particularly for my choice of wording in documentation changes. The final push will differ slightly from this, especially if the autoconf patch going in first changes slightly due to review there, but this should give a good idea of the fix. Eric Blake (2): mountlist: include sysmacros.h for glibc sys_types: avoid glibc 2.25 warnings about major() ChangeLog| 15 +++ doc/glibc-functions/gnu_dev_major.texi | 4 doc/glibc-functions/gnu_dev_makedev.texi | 4 doc/glibc-functions/gnu_dev_minor.texi | 4 doc/posix-headers/sys_types.texi | 6 ++ lib/mountlist.c | 6 ++ m4/mountlist.m4 | 3 ++- m4/sys_types_h.m4| 27 ++- 8 files changed, 67 insertions(+), 2 deletions(-) -- 2.7.4 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: m4_divert_text
On 09/14/2016 07:26 AM, Russell Shaw wrote: > Hi, > > In binutils/configure.ac there is: > > m4_divert_text([PARSE_ARGS], > [case $srcdir in > *" "*) > m4_pushdef([AS_MESSAGE_LOG_FD], [])dnl > AC_MSG_ERROR([path to source, $srcdir, contains spaces]) > m4_popdef([AS_MESSAGE_LOG_FD])dnl > ;; > esac > ac_subdirs_all=`cd $srcdir && echo */configure | sed 's,/configure,,g'` > ]) > > > I can't find where it's used, and was wondering how one would use this > definition. AS_MESSAGE_LOG_FD is documented; https://www.gnu.org/software/autoconf/manual/autoconf.html#AS_005fMESSAGE_005fLOG_005fFD. But let's look at what happens here. AC_MSG_ERROR is a synonym for AS_ERROR, and the definition of AS_ERROR is: m4_defun_init([AS_ERROR], [m4_append_uniq([_AS_CLEANUP], [m4_divert_text([M4SH-INIT-FN], [_AS_ERROR_PREPARE[]])])], [as_fn_error m4_default([$2], [$?]) "_AS_QUOTE([$1])"m4_ifval(AS_MESSAGE_LOG_FD, [ "$LINENO" AS_MESSAGE_LOG_FD])]) That is, the result of invoking AC_MSG_ERROR is a shell-script call to the function as_fun_error, with either 2 arguments (the error code and message) or 4 arguments (the error code, message, current line number, and log fd), based on whether the current macro definition of AS_MESSAGE_LOG_FD is blank. Looking at that shell function, it behaves differently according to whether the third and fourth arguments are present, by additionally logging to the log fd. So what binutils is doing is writing a low-level macro where they DON'T want the message logged to config.log, so they temporarily redefine AS_MESSAGE_LOG_FD to the empty string around the duration of the expansion of AC_MSG_ERROR, in order to change how that macro is expanded. > > Doesn't the pushdef/popdef pair make it useless? No, the pushdef/popdef pair is what makes it so that the temporary non-logging nature of AC_MSG_ERROR() lasts only for the duration of the expansion of this snippet, rather than the rest of configure.ac. -- Eric Blake eblake 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: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
On 09/13/2016 05:31 PM, Eric Blake wrote: [hit send too soon] > Okay, I have confirmed that this prime-the-cache idea DOES work, using > libvirt.git commit 419bc8cf (one commit prior to d53fa838 which > installed a hack into libvirt to force the use of -Werror for the > duration of AC_HEADER_MAJOR [1]). By itself, './configure' succeeds but > leaves MAJOR_IN_SYSMACROS undefined, which results in a build failure > later in libvirt; but when run as './configure > ac_cv_header_sys_types_h_makedev=no', MAJOR_IN_SYSMACROS gets defined > and the build succeeds. I meant to add this link: [1] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=d53fa838 -- Eric Blake eblake 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: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
[adding libvirt list, as this is what sparked my investigations so far today] On 09/13/2016 04:36 PM, Eric Blake wrote: > One other possibility that distros can do is to prime a config.site > file, with $ac_cv_header_sys_types_h_makedev=no, to forcefully bypass > the configure check that is normally done where would > warn. It has to be in config.site, because non-glibc systems do not > want to do that. Okay, I have confirmed that this prime-the-cache idea DOES work, using libvirt.git commit 419bc8cf (one commit prior to d53fa838 which installed a hack into libvirt to force the use of -Werror for the duration of AC_HEADER_MAJOR [1]). By itself, './configure' succeeds but leaves MAJOR_IN_SYSMACROS undefined, which results in a build failure later in libvirt; but when run as './configure ac_cv_header_sys_types_h_makedev=no', MAJOR_IN_SYSMACROS gets defined and the build succeeds. I want to remove the libvirt hack (not all compilers understand -Werror, even if libvirt is only ever built by gcc or clang), and my experiment was enough to prove that: 1. distros that provide a config.site file can use this file to avoid the problem, even for packages that have not yet rebuilt with a new-enough autoconf to fix the issue 2. autoconf and gnulib should indeed be fixed to probe for _prior_ to probing for whether makedev() exists in , rather than the 2.69 logic of only checking for if makedev() was not found earlier. Of course, the libvirt hack should not be reverted until autoconf and gnulib have the final solution in place. > > Meanwhile, even without an autoconf release scheduled, I am currently > working on patching the existing autoconf macro and documentation to > match the current situation. It sounds to me like we want the following > logic: > > If exists and defines major(), use that, > else if exists, use that, > else if defines major(), use that, > else not available The current autoconf code assumes that if exists, then it defines major()/minor()/makedev(); I think that assumption is still safe. Where autoconf was wrong was that it was not even probing for the existence of if it found that was enough to pollute the namespace with the three macros. -- Eric Blake eblake 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: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
On 09/01/2016 08:16 PM, Zack Weinberg wrote: > AC_HEADER_MAJOR is obeying the letter of its documentation but not the > spirit. People using it reasonably expect that it should handle this > transition seamlessly for them. They've already gone to the trouble > of writing > > #include > #ifdef MAJOR_IN_MKDEV > #include > #elif MAJOR_IN_SYSMACROS > #include > #endif > > and shouldn't that be enough, not only to keep their program working > when glibc actually pulls the plug on the definitions in > , but to avoid the deprecation warnings? The autoconf manual currently doesn't say how to USE the results of AC_HEADER_MAJOR - it only states that MAJOR_IN_MKDEV or MAJOR_IN_SYSMACROS might be defined. But your formulation of the correct usage _looks_ correct to me, and probably SHOULD be in the manual. At which point, the remaining trick to solve is that autoconf SHOULD be setting MAJOR_IN_SYSMACROS for glibc, but isn't, because it short-circuits at the point where it sees the pollution in . I think that rewriting the macro to check for _first_, not last, will get MAJOR_IN_SYSMACROS set; and then if programs ARE using the formulation you spell out above, then we have the desired situation that configure works and the code compiles without warnings. Of course, if there were a way for glibc to detect that it was being run under autoconf, and in that situation intentionally refuse to declare major/minor/makedev, then existing autoconf clients will already fall back to defining MAJOR_IN_SYSMACROS. I just don't know if I feel comfortable with glibc mucking with the build to compile one way under autoconf and another way in real life, as autoconf's goal is to see what will happen in real life. -- Eric Blake eblake 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: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
On 09/01/2016 08:08 PM, Zack Weinberg wrote: > On Wed, Aug 31, 2016 at 11:24 PM, Paul Eggert wrote: >> Zack Weinberg wrote: >>> Have I missed either a way to carry out the ideal solution, or a third >>> alternative? >> >> How about changing AC_HEADER_MAJOR to detect those warning messages? > > That's difficult, but more importantly it doesn't do any good till we > get an autoconf release out -- and then everyone using AC_HEADER_MAJOR > has to regenerate their configure script and release *their* software. > I'm hoping we can find a solution that can be implemented entirely > within glibc. I may be able to get some time at my $dayjob to get an autoconf release out the door before the glibc release; how much time do I have left, to know what priority I need to give this? And you are correct that a new autoconf won't help projects that don't re-run autoconf with the fix, but at a bare minimum, we can at least get gnulib to support the same macro definition as what autoconf 2.70 will have, so that projects using gnulib will at least not have to wait for an autoconf release, as well as having updated docs in the released autoconf manual that tell users what to do when they run into the problem. One other possibility that distros can do is to prime a config.site file, with $ac_cv_header_sys_types_h_makedev=no, to forcefully bypass the configure check that is normally done where would warn. It has to be in config.site, because non-glibc systems do not want to do that. Meanwhile, even without an autoconf release scheduled, I am currently working on patching the existing autoconf macro and documentation to match the current situation. It sounds to me like we want the following logic: If exists and defines major(), use that, else if exists, use that, else if defines major(), use that, else not available instead of the current broken logic: If defines makedev(), use that, else if exists, use that, else if exists, use that, else not available Does anyone see any flaws in my reasoning? I'll post a patch as a followup, if it passes testing on my end (I'm using Fedora rawhide as my testbed, which is definitely hitting the compilation failure with current glibc). -- Eric Blake eblake 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: Control of .deps folder generation location.
On 09/07/2016 02:42 AM, Bent Bisballe Nyeng wrote: > Hi list > > I have a project in which I include a few out-of-tree cpp files in one > of my SOURCES directives. > > I am currently trying to use the new subdir-objects argument but am > having the problem that autoconf tries to write a .deps folder to the > folder containing the out-of-tree files which is located in a system > folder and therefore not writable to the user. > > Is it possible to somehow force autoconf to write this .deps folder in a > location inside the project tree? Creation of .deps folders is done by automake, not autoconf. You may get a better answer from the automake lists. However, having out-of-tree files as part of your project seems fishy; as I understand it, automake works under the assumption that every cpp file being compiled is part of the distribution tarball, so that the build is reproducible (someone unpacking your tarball on their system would otherwise have to guarantee they have the same out-of-tree cpp files as you were building with). > Or can I perhaps resolve my issue in another way? > (I would really like avoid having to copy the out-of-tree cpp files to > an in-tree folder before compilation) But how are you making the tarball work, without those out-of-tree cpp files? -- Eric Blake eblake 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: Question on configure summary with subpackages
On 09/02/2016 08:45 AM, Juergen Reuter wrote: > Dear all, > I'm using autoconf for my software package which has several subpackages > included via the AC_CONFIG_SUBDIRS. The configure output then looks like > this: > > > > > > Is it possible to get a configure summary for the whole package > after the output of the last subpackage n? (a summary that e.g. > contains information on chosen options, enable features etc.) > Any help would be much appreciated! Per the documentation, any code you put after AC_OUTPUT is run after config.status (and thus the subconfigures) have been run. So you can add shell code to your top-level configure.ac that summarizes whatever it wants, and that code will execute (and thus output) after the subpackage configure output. However, it may be trickier to figure out how to make the parent configure report the status of decisions that were only made within a subconfigure (there's an obvious flow of information from parent to child, but pretty much only exit status and scraping log files to get information from child back to parent). -- Eric Blake eblake 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: Release Autoconf 2.70
On 07/21/2016 12:25 AM, Marko Lindqvist wrote: > On 21 July 2016 at 00:06, Eric Blake wrote: >> On 07/20/2016 11:21 AM, Craig Andrews wrote: >>> >>> what's >>> blocking a release? >> >> Lack of free time from someone with commit rights. > > How much time it takes to make a release? For the outsider there's > not many obviously needed steps that take a lot of time. Does making a > RC take as much time as full release, or could we have RC for testing > both autoconf and the build systems of projects that use it? > The biggest time sink is digging through the mail archives to ensure that all posted patches that are still relevant have been applied; I know that there is a big body of work for detecting compiler warnings that needs to be reviewed and incorporated. -- Eric Blake eblake 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: Release Autoconf 2.70
On 07/20/2016 11:21 AM, Craig Andrews wrote: > There have been a number commits made to autoconf since 2.69 was > released on April 24, 2012. FWIW, I'm particularly interested in the > runstatedir change. > > Is it possible to make a 2.70 release in the near future? If not, what's > blocking a release? Lack of free time from someone with commit rights. -- Eric Blake eblake 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: Detect Autoconf run in preprocessor?
On 07/15/2016 01:00 PM, Jeffrey Walton wrote: >> Autoconf does not define anything specific. You can write an early >> AC_DEFINE in your configure.ac to trigger a specific witness used in all >> subsequent probes, but that's a per-package solution. > > Perfect, thanks. > > Can the Autoconf folks recommend a name for the define? Maybe > something like GNU_AUTOCONF or similar? The point of autoconf is to probe what your system behaves like when autoconf is not running. If you are writing headers that specifically behave differently during configure than they do in normal usage, that goes contrary to the goal of autoconf. I don't quite know what problem you are up against, but the best autoconf tests are the ones written as close to normal usage as possible, not ones that specifically try to circumvent normality. -- Eric Blake eblake 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: Detect Autoconf run in preprocessor?
On 07/15/2016 12:47 PM, Jeffrey Walton wrote: > On Fri, Jul 15, 2016 at 2:35 PM, Bob Friesenhahn > wrote: >> On Fri, 15 Jul 2016, Jeffrey Walton wrote: >>> >>> >>> Is there a preprocessor macro defined by Autotools to detect when >>> software is being configured by the tool? My apologies for asking; I >>> cannot simply run `g++ -dM -E - >> Autoconf specific defines. >> >> >> Everything that Autoconf defines should be visible in the generated >> config.log file. The source for each test case is included. > > Thanks. I'll have to ask the person for it. > > But getting back to Autoconf defines, is there a preprocessor define > that Autoconf uses to identify itself? Autoconf does not define anything specific. You can write an early AC_DEFINE in your configure.ac to trigger a specific witness used in all subsequent probes, but that's a per-package solution. -- Eric Blake eblake 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: running autoconf in chrooted environments
On 07/07/2016 02:15 PM, Peter Crady wrote: [your mailer isn't configured to wrap long lines, which makes it harder to read and reply] > This may be a stupid question but is there a good way to run autoconf in a chrooted environment? Do it the same way you run any other program - just run it. Remember, if you have to modify autoconf to behave differently, then you would have to modify every other program in the chroot environment in the same manner; the whole point of autoconf is to probe the actual environment it is running under. So if autoconf isn't getting the answers you want, then it is your environment at fault, not autoconf. And these days, chroot'd environments aren't as secure as cgroups, containers or virtual machines, so you may want to look into those technologies for better isolation of your test environment from your host environment. > From what I can tell the AS_UNAME function calls uname which gets information about the base kernel that is installed and not the kernel that is installed in the chrooted environment. If you're referring to uname(1) (the command line utility run by AS_UNAME), then it is up to you whatever uname(1) binary you installed into your chroot. If your uname(1) binary isn't returning the information you want, then it's your fault for building an incomplete chroot. And if your uname(1) in the chroot is returning the modified information, then AS_UNAME will see that modified information, not the base kernel information. If you're referring to uname(2) (the system call, which is generally what gets used under the hood by the uname(1) binary), then that depends on whatever kernel is actually running the binary that makes the syscall. If you are using merely chroot, then yeah, things are being run by a single kernel (chroot isolates files, but not the kernel used to run the files); which is where other technologies like containers (such as docker) or virtual machines (such as qemu) indeed let you turn on even more pieces to the point of completely running your test as if it were a different machine and kernel than the host. -- Eric Blake eblake 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: Using "m4_bpatsubst/patsubst" to remove a string from a variable
On 06/06/2016 07:31 AM, Zack Weinberg wrote:
> or you can do it all in shell:
>
> VAR="text1 text2"
> VAR2="`AS_ECHO("$VAR") | sed 's/text1//g'`" dnl yes, the nested double
> quotes are correct
Correct in a POSIX shell, but liable to misbehave on some older shells.
Better is:
VAR2=`AS_ECHO("$VAR") | sed 's/text1//g'`
Since it is in assignment context, you don't need the outer "" to
prevent word splitting, the `` is enough for the shell to know where the
assignment ends.
--
Eric Blake eblake 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: Call the AC_CHECK_HEADER macro on a condition
On 04/12/2016 09:05 AM, Nick Bowler wrote: > > But in your second instance, the first expansion of AC_CHECK_HEADER > expands AC_PROG_CPP inside an "if". The result is that no preprocessor > is checked in the "else" case. You can see this in the configure output, > the following line is only printed in the avr case: > > checking how to run the C preprocessor... avr-gcc -E > > There are several basic solutions: > > - First, you can just expand AC_PROG_CPP directly and unconditionally > before your if. This will ensure the macro is available in both cases. > > - Second is to rewrite your condition using AS_IF, which automatically > "hoists" the dependency AC_PROG_CPP (and any other dependencies) > outside of the if condition. For example: > > AS_IF([test x"$host" = x"avr"], > [AC_CHECK_HEADER([avr/io.h], [], > [AC_MSG_ERROR([missing header: avr/io.h])]) > AC_CHECK_HEADER([util/delay.h], [], > [AC_MSG_ERROR([missing header: util/delay.h])])], > > [AC_CHECK_HEADER([stdio.h], [], > [AC_MSG_ERROR([missing header: stdio.h])]) Also, checking for is pointless these days. You can portably assume a C89 compiler (and these days, often a C99 compiler), which guarantees is present. -- Eric Blake eblake 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: m4_set_contains cannot find key
On 03/18/2016 05:39 AM, Petre Pircalabu wrote: > Please disregard this question. The m4 preprocessing is done before > "configure", so the m4 preprocessor has no way of knowing about the > variable. Correct - you were mixing two languages (m4 and shell), and which gets run when. >> m4_set_add([food], [fish]) >> m4_set_add([food], [steak]) >> m4_set_add([food], [junk]) >> >> meal=junk >> >> AC_MSG_CHECKING([whether we have junk food for dinner]) >> m4_set_contains([food], [$meal], [VAL="yes"], [VAL="no"]) The literal string '$meal' (at m4-time) is NOT in the set, so the m4 result of the expansion is always going to trigger the 'VAL="no"' branch. If you want to see if the contents of a shell variable are in a shell set, then m4_set_* is not the right construct to be using. -- Eric Blake eblake 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: Automatic autoheader invocations for AC_DEFINE changes in m4-files
On 02/10/2016 01:10 PM, Marko Lindqvist wrote: > We have had no problems with patches that do that for macros > AC_DEFINEd in configure.ac. When one runs 'make', both the full and > public header are correctly generated. > However, when the macro in question in one patch was AC_DEFINEd in a > separate m4-file, 'make' was not enough at all. Template for the full > header did not update until manual autoreconf. This is more of an automake question than an autoconf one (since it is automake that generates the make rules for what needs to be rebuilt when). Do you have AC_CONFIG_MACRO_DIR([...]) in your configure.ac, pointing to the location of your .m4 files? Likewise, in your Makefile.am, do you have ACLOCAL_AMFLAGS = -I path/to/m4? I've found in my projects that both places are needed to inform automake that it must generate proper dependency tracking so that a change to a .m4 file forces an automatic autoreconf. -- Eric Blake eblake 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: Using autotest with Emacs’ compilation mode
On 02/03/2016 05:39 AM, Nikolai Weibull wrote: > Hi! > > I don’t want to be a nag, but does anyone have any input on this? Why > has the testsuite output been designed this way? You're more than welcome to submit patches. The shortcomings in the testsuite are likely due to being written by people that aren't familiar with using emacs' compilation mode, so we didn't know any better - so having patches on hand rather than just descriptions of what is wrong will make it easier to fix. > > On Sat, Jan 30, 2016 at 1:23 PM, Nikolai Weibull wrote: > >> Since there hasn’t been any responses yet, let me fill in the blanks, >> as I see them. >> >> On Fri, Jan 29, 2016 at 9:18 PM, Nikolai Weibull wrote: >> >>> A question to all you users of Autoconf and Emacs: How are you using >>> autotest with Emacs’ compilation mode? >>> >>> The output of an autotest testsuite isn’t really suited for Emacs’ >>> compilation mode, as the paths to tests are, at least when using a >>> separate build directory, not correct. >> >> Here’s a, most likely incomplete, list of issues with the testsuite >> regarding paths: >> >> 1. The -C option doesn’t have a corresponding -w and --print-directory >> (and --no-print-directory) option to output the directory it’s >> changing to, which means that paths can’t be tracked by Emacs. Seems like it would be a useful addition. >> >> 2. The path stored in $at_check_line_file is always relative to the >> location of testsuite. It should be relative to $at_dir. >> >> 3. The path stored in $at_setup_line is always relative to the >> location of testsuite. It should be relative to $at_dir. Seems like those would be sane bug fixes. >> >> 4. The path stored in $at_group_log to the command being executed >> should be relative to the location of $at_group_log. This is probably >> hard to fix using relative directories, as the path is also output to >> the terminal in verbose mode (via $at_tee_pipe) and in this case the >> path should be relative to $at_srcdir (as it is today). >> >> 5. It would be useful if there was a way to include the path to the >> log file in the output, perhaps enabled via an option, so that Emacs’ >> compilation mode could pick it up for next-error. May take more code to write, but seems like it would be okay if we have a patch to evaluate. >> >>> Also, how do you check the logs of failed tests effectively when a test >>> fails? >> >> Here’s a list of issues with the log files that open up in compilation mode: >> >> 1. The log sets up compilation mode (via “-*- compilation -*-”), but >> it doesn’t set default-directory, meaning that relative paths are >> relative to the log instead of to the directory where compilation took >> place. >> >> 2. The log doesn’t set compile-command, which could theoretically be >> set to “run” to re-run the test. It might be necessary to set >> compile-directory as well. How best to fix that? By adding more comment text into the log file? >> >> 3. Executing recompile (g) from one of these log files will replace >> the content of the log with the output of the compilation, as Emacs >> will reuse the buffer. I’m not sure how you’d get Emacs to (re-)use >> the “*compilation*” buffer, as compilation-buffer-name-function can’t >> safely be set via a file-local variable, so this might have to be >> fixed in Emacs. > -- Eric Blake eblake 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: [Qemu-devel] [Bug 1525682] Re: configure: fix POSIX compatibility issue
[adding autoconf, which likes to document shell bugs]
On 12/14/2015 04:34 AM, Dmitrij D. Czarkoff wrote:
> OK, so I misidentified the issue and screwed up my bug report.
>
> The shell is pdksh on OpenBSD, and the real issue is with parentheses:
>
> $ a=1
> $ b=2
> $ echo "${a+($b)}"
> ksh: ${a+($b)}": bad substitution
That's a bug in pdksh; see the POSIX interpretation:
http://austingroupbugs.net/view.php?id=221#c399
For parameter expansions other than the four varieties that provide
for substring processing, within the string of characters from an
enclosed "${" to the matching '}', the double-quotes within which
the expansion occurs shall preserve the literal value of all
characters, with the exception of the characters double-quote,
backquote, , and .
The fact that you are using "" outside the ${} means that all characters
between + and } should be used literally (the same as if you had done
'echo "($b)"'). According to POSIX, it should not be a syntax error, so
you should report this to the pdksh shell developers.
--
Eric Blake eblake 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: How to programmatically detect awk flavor (e.g. gawk vs mawk vs nawk vs awk)
On 10/18/2015 11:31 AM, Itamar Gal wrote: > Hey autoconf gang, > > I recently posted a question to unix.stackexchange.com asking for the best > way to programmatically determine which flavor of awk is present on a given > host. In the autoconf philosophy, does it really matter? Either write your awk script to be common to the lowest denominator of the awk implementations, or pick a feature that you want to use from a given awk implementation and probe that the particular feature is supported (regardless of which flavor of awk is running the probe script). If you do only feature probes, rather than version/implementation probes, then it won't hurt if some implementation later gains the feature you were probing for. > > Someone suggested using the AC_PROG_AWK macro, but didn't elaborate on how > this would work. Unforunately I'm only passingly familiar with the GNU > build system and I can't quite make sense of the autoconf source code that > I've looked at (e.g. programs.m4 and autoconf.m4f). > > Can anyone here explain to a novice like me how I might be able to make use > of this macro to construct a simple bash script which determines which > variety of awk is in the path? The expansion of that macro demonstrates how to probe whether a given awk meets certain minimum capabilities, via feature probes. To use additional features, you would extend the number of feature probes being done in that sort of feature probing loop. For seeing what the actual macros do, it may be easier to read the expanded results in a configure file, than it is to read the pre-expanded m4 code in programs.m4, to get a better feel for the shell code emitted for probing for awk. Probably not the best answer, but I'm also not the best awk expert around here. Good luck -- Eric Blake eblake 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 Digest, Vol 138, Issue 2
On 10/09/2015 01:06 PM, Keith Bostic wrote: > I was wondering if there were plans to do an autoconf release? It's on my list of things to do when I have a dedicated day to spend on it, but sadly that day has not come up yet ($DAYJOB efforts trump volunteer efforts, sometimes). I'm still hoping to get to it in 2015, though. -- Eric Blake eblake 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: autocon and sub-packages
On 09/03/2015 08:09 AM, Sébastien Hinderer wrote: > Dear all, > > I am one of the maintainers of Coccinelle[1], a tool written in the > Objective Caml[2] language. > > The tool is distributed with the libraries it depends on (they are > provided as bundles). At one point, this was how both libintl (gettext) and libltdl (libtool) were primarily used - many packages would include subdirectories with the appropriate bundled library, and then rely on macros provided by gettext/libtool to probe whether to favor the system version if present and capable, otherwise fall back to the bundled version. However, these days, most people have leaned towards excluding the bundle, and instead requiring the external library to be present. For more information, check out: https://www.gnu.org/software/gettext/manual/gettext.html#AM_005fGNU_005fGETTEXT https://www.gnu.org/software/libtool/manual/libtool.html#Distributing-libltdl > Then, assuming we continue to bundle the dependencies, it seems to me > that it would be more coherent to have the configure script of each > required bundle run by the tool's main configure script. I am aware of > the AC_CONFIG_SUBDIRS macro, but this seems a bit limited to me. For > instance it means that the sub-package's configure may find a different > compiler to use than the one found by the main conigure, which is not > good. I'm not sure why you think a different compiler would be picked for a sub-package. Particularly if $CC is set in the parent package before calling out to the sub-packages, then the sub-packages should see $CC in the environment and favor that as their compiler. But I don't have much experience with bundled libraries (as I have moved strongly to the camp of require the external library to be present, now that both gettext and libtool have made that easier to be the default), to know for sure. > > One other issue is that we bundle the dependencies as .tar.gz archives > and we would like to be able to extract the archives only for those > dependencies that will really be needed (because they are not already > installed on the system). Can this be achieved somehow with autoconf? If you can come up with appropriate shell code to do that, then you can embed that shell code in your configure.ac. I don't know of any autoconf macros that would automate some of the work, but it sounds like it might be something that could be cobbled together, if you still want to go the route of shipping dependent library bundles. -- Eric Blake eblake 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: Instructions to compile and install autoconf
On 08/21/2015 06:14 PM, Vishnu Vardhan Makkapati wrote: > Hi > > I downloaded autoconf using git. But I do not find a configure script that I > generally use to configure and build applications. The INSTALL file is also > missing. Can you send me detailed set of instructions to compile and install > autoconf? > http://www.gnu.org/software/autoconf/autoconf.html > <http://www.gnu.org/software/autoconf/autoconf.html> > You have hit a common misconception. You only NEED to use autoconf.git if you plan on contributing patches to autoconf. Most people don't fall into this category. Use a pre-built autoconf from your distro, or use an existing autoconf.tar official release instead. But if you really DO want to develop autoconf, then you have to bootstrap your system by first installing autoconf from a tarball, and using that to run 'autoreconf -vf' on your git checkout, in order to get the required configure file located within your checkout. For more details, see this mail that I sent a couple months ago: https://lists.gnu.org/archive/html/m4-discuss/2015-06/msg1.html > IMPORTANT NOTICE: This e-mail, including any attachments, may contain > confidential information and is intended only for the addressee(s) named Please don't include this sort of legalese on mail sent to public lists, where it is unenforceable. It is better to send from your own email instead of from your company's if your company forces you to append such garbage. -- Eric Blake eblake 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: Trouble submitting patch
On 08/17/2015 04:41 AM, Daniel Elstner wrote: > Hi, > > I've created a patch for autoconf and sent it to autoconf-patches. > However, it does not seem to appear on the list. I've already tried > sending it a second time, to no joy. > > Am I doing something wrong? The patch appears now. As with most gnu lists, there is a first-time posting delay through a human moderator to whitelist your email as a non-spammer; and the process can take up to 24 hours (particularly over a weekend). Once one message gets through, your followups will no longer be delayed. -- Eric Blake eblake 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 execution needs root permission
On 05/12/2015 12:46 AM, Marslo Jiao wrote: > Hi, > > I've heard of my colleague said that, if we use autoconf, then it must need > root permission. > Is that right? No, you are mistaken. Autoconf is designed to be usable without requiring any special permissions. I'd be interested in more details as to why you think root access is required, to help squash an incorrect notion with more facts than just a blanket statement. There are some configure scripts in the wild that were written where a particular test will get a correct answer only when configure is run as root, but such packages are the minority. But such a configure script can still be generated in user space without root privileges, and the test in those configure scripts is a result of whoever wrote that configure.ac, and not due to autoconf proper. -- Eric Blake eblake 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: sysconfdir
On 03/19/2015 03:49 PM, Roman Neuhauser wrote:
> sysconfdir is defined as '${prefix}/etc', but configure --prefix=/usr
> should imply sysconfdir='/etc' (or should it?).
--prefix=/usr should imply sysconfdir='${prefix}/etc' UNLESS you have
installed a config.site that says otherwise (which, thankfully, more and
more distros are starting to do).
>
> what does everybody do to get stuff under "/etc"?
They install a /usr/share/config.site file that overrides sysconfdir as
needed:
https://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults
--
Eric Blake eblake 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: m4_pattern_forbid
On 03/17/2015 06:02 PM, Matěj Týč wrote: > > What is interesting: I wanted to point out that it should be more > appropriate to write m4_pattern_forbid([\bMACRO]) than ...([^MACRO]), > but I found out that it is not really the true: The perl code in autom4te splits all words of the input into one word per line before running the regex. > > cat << EOF | autom4te -l m4sugar > m4_pattern_forbid([^FOO]) > m4_divert_push(1)dnl > FOO1 > FOO2 > hidden FOO3 so all three instances of these FOO match the pattern to be rejected (after being rewritten as: FOO1 FOO2 hidden FOO3 before testing the regex) > hiddenFOO4 and this does not. > So maybe getting involved \b is not needed under these circumstances? The accept/reject patterns operate on each word as if on the line by themselves, so no need to use \b. -- Eric Blake eblake 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: named diversions
On 03/16/2015 06:12 PM, Matěj Týč wrote: >> According to the manual, m4sugar defines KILL and GROW as named >> diversions; m4sh (if you use AS_INIT instead of m4_init) also adds >> BINSH, several HEADER-*, M4SH-SANITIZE, M4SH-INIT, and BODY. That is, >> if you are using autom4te to generate a shell script, then you >> eventually want to m4_divert_push([BODY]) (although you get it free by >> using AS_INIT). >> >> As for creating new named diversions, they are not documented in the >> manual, but you can learn about them in the m4sugar source code >> (basically, m4_define([_m4_divert(NAME)], NUMBER) will define >> m4_divert_push(NAME) to use that diversion number). > Thank you for your reply! > I use m4sugar to create a file (a DB schema, a .dot file, ... - not a > bash script), so I don't want to involve m4sh.I simply manually call > autom4te -l m4sugar on definition files. Interesting. I'm not aware of any other major clients of just m4sugar outside of autoconf (I do know that libtool uses m4sh outside of autoconf, but that's higher than m4sugar); but I also agree that avoiding m4sh makes sense in your use. > The GROW diversion seems to work nicely, but the documentation somehow > discourages using it in that way since it has another purpose (... is > used behind the scenes by topological sorting ...). Correct (in particular, m4_require and friends make use of it). > However, your advice works, one can register new diversions exactly in > the way you have described, I have defined a new diversion No. 1 as > STDOUT. Wouldn't make such diversion sense in m4sugar? I wouldn't want it in m4sugar, as none of the other layers on top of it would use it; but just as m4sh, autotest, and autoconf have each added named diversions, I see no issue with you adding it in your layer. > Anyway, I would like to add the documentation about this diversion stuff > too. Are you OK with that? I'm not sure how much documentation we need (most of this won't be used by the common configure.ac writer) vs. better comments in m4sugar.m4 but out of the manual. As it is, I think that documenting anything in the '_m4_' namespace (such as _m4_divert(NAME)) in the manual is unwise, and that if we really wanted to document creating new defined names, we'd need to rework the code to avoid the internal namespace. But you're certainly welcome to submit patches if you think it would be useful for the next person trying the same task (maybe even by defining some sort of wrapper of m4_create_named_divert([name], [number]) which defines the internal _m4_divert(NAME) under the hood). -- Eric Blake eblake 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: named diversions
On 03/14/2015 05:01 PM, Matěj Týč wrote: > Hello again, > In my m4 project where I use autom4te and m4sugar (for those who are > curious - https://github.com/matejak/d8 ), > in order to be able to output anything, one has to call > m4_divert_push(1) (or something similar) at certain point. However, > every time I do that, I get the > warning: prefer named diversions > warning. I know that I can use m4_divert_push(KILL) in place of > m4_divert_push(0), but a trivial diversion e.g. for stdout is not > available (or documented). There is also a lack of documentation on how > to register a named diversion, using a macro instead of a number isn't > the right way how to make a named diversion. > Do you have any solution to this in mind? Telling autom4te to suppress > warnings doesn't feel right. According to the manual, m4sugar defines KILL and GROW as named diversions; m4sh (if you use AS_INIT instead of m4_init) also adds BINSH, several HEADER-*, M4SH-SANITIZE, M4SH-INIT, and BODY. That is, if you are using autom4te to generate a shell script, then you eventually want to m4_divert_push([BODY]) (although you get it free by using AS_INIT). As for creating new named diversions, they are not documented in the manual, but you can learn about them in the m4sugar source code (basically, m4_define([_m4_divert(NAME)], NUMBER) will define m4_divert_push(NAME) to use that diversion number). -- Eric Blake eblake 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: m4_pattern_forbid
On 03/12/2015 04:36 PM, Matěj Týč wrote: > Hello, > I am doing some m4sugar programming and I found the m4_pattern_forbid > insufficient. > As we all know, there are many kinds of regular expression in different > programs and even on different OSs (grep, vim, Python, linux sed, osx > sed, ...). So my question is - where should I look to learn what kind of > regular expression I can specify to that macro? It is an extended regular expression according to what perl understands (which is similar to what 'grep -E' understands). > > Interestingly, I took a look at the autoconf/m4sugar/m4sugar.m4:2005 to > learn the definition and I was surprised by what I have found there: > > # m4_pattern_forbid(ERE, [WHY]) > # - > # Declare that no token matching the forbidden extended regular > # expression ERE should be seen in the output unless... > m4_define([m4_pattern_forbid], []) > > I was unable to find the true macro's definition anywhere, so here is > the second question: How (and where) is m4_pattern_forbid defined? That's exactly where it is defined in m4. What you are really looking for is the code that traces all no-op uses of that definition and then greps the output for those forbidden patterns. For that, look at bin/autom4te.in, for 'sub warn_forbidden'. It is one of several m4sugar constructs that is done by the autom4te perl wrapper that invokes m4 and post-processes the output, rather than directly by m4. Would you like to propose a documentation patch to make it clear that the flavor of regex in use by this macro is what perl understands? -- Eric Blake eblake 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: emacs autoconf mode
On 02/13/2015 07:47 PM, Harlan Stenn wrote: > Eric Blake writes: >> On 02/13/2015 01:35 AM, Harlan Stenn wrote: >>> Is there a good autoconf mode out there that will help me make sure >>> the autoconf macros are "properly" indented? >> >> Not that I'm aware of, but if you find one, be sure to post a link to >> it back here (the emacs file in the autoconf.git repository hasn't >> been touched in ages, and might benefit from improvement if a better >> module out there). > > How big a job would it be to write something that did this well? Not sure - I've never personally written an emacs mode. > > Would this be a good GSoC project? Couldn't hurt to try. -- Eric Blake eblake 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: emacs autoconf mode
On 02/13/2015 01:35 AM, Harlan Stenn wrote: > I've seen http://www.emacswiki.org/emacs/AutoconfMode and since I'm a > bit overwhelmed these days, I figured I'd just ask: > > The last time I checked either of the recommended packages, I thought > neither handled indentation well. > > I've got a situation where I need to do a bit of surgery on a fairly big > autoconf macro file, and that file is not well indented. > > Is there a good autoconf mode out there that will help me make sure the > autoconf macros are "properly" indented? Not that I'm aware of, but if you find one, be sure to post a link to it back here (the emacs file in the autoconf.git repository hasn't been touched in ages, and might benefit from improvement if a better module out there). -- Eric Blake eblake 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
