| Message ID | 20200105210421.591401-1-eschwartz@archlinux.org |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | [pacman-dev] autotools: emit error message when autoconf-archive is missing | expand |
Thanks for the wonderful explanation. Still, I get an error. $ autoreconf -vif && ./configure --prefix=$HOME/pacman/usr/local $ make install ... libmakepkg/executable/checksum.sh: line 33: syntax error near unexpected token `<' libmakepkg/executable/checksum.sh: line 33: ` mapfile -t integlist < <(get_integlist)' make[3]: *** [Makefile:990: libmakepkg/executable/checksum.sh] Error 2 make[3]: *** Waiting for unfinished jobs.... GEN libmakepkg/integrity.sh GEN libmakepkg/buildenv/buildflags.sh GEN libmakepkg/buildenv/makeflags.sh GEN libmakepkg/buildenv/debugflags.sh GEN libmakepkg/buildenv/compiler.sh make[2]: *** [Makefile:699: all-recursive] Error 1 make[1]: *** [Makefile:993: all-recursive] Error 1 make: *** [Makefile:902: all] Error 2 The full log is ~46MiB: http://nly.info.tm:9001/log/pacman2 However, some files seem to be installed. $ ls $HOME/pacman/usr/local/bin/ pacman pacman-conf testpkg vercmp Thanks, Amar
On 1/5/20 5:12 PM, nly@disroot.org wrote: > Thanks for the wonderful explanation. > > Still, I get an error. > > $ autoreconf -vif && ./configure --prefix=$HOME/pacman/usr/local > $ make install > ... > libmakepkg/executable/checksum.sh: line 33: syntax error near unexpected token `<' > libmakepkg/executable/checksum.sh: line 33: ` mapfile -t integlist < <(get_integlist)' > make[3]: *** [Makefile:990: libmakepkg/executable/checksum.sh] Error 2 > make[3]: *** Waiting for unfinished jobs.... This happens while running: make -C scripts libmakepkg/executable/checksum.sh The error you are getting is that this is not valid: mapfile -t integlist < <(get_integlist)' After every file generation, the Makefile will execute: @$(BASH_SHELL) -O extglob -n $@ That is, it is running the file using bash's "-n" option; set -n will cause the file to be read, but no commands to be executed, in an effort to make sure the file works. This is why you are getting messages about the syntax of the file. So the question then is, what is this resolving to? checking for bash... /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash It needs to be bash >= 4.4.0, and we have a check which is supposed to enforce this: https://git.archlinux.org/pacman.git/tree/configure.ac?h=v5.2.1#n201 What version is your bash program, and why might it be refusing to recognize this bash syntax? > GEN libmakepkg/integrity.sh > GEN libmakepkg/buildenv/buildflags.sh > GEN libmakepkg/buildenv/makeflags.sh > GEN libmakepkg/buildenv/debugflags.sh > GEN libmakepkg/buildenv/compiler.sh > make[2]: *** [Makefile:699: all-recursive] Error 1 > make[1]: *** [Makefile:993: all-recursive] Error 1 > make: *** [Makefile:902: all] Error 2 > > The full log is ~46MiB: http://nly.info.tm:9001/log/pacman2 Aside: that log is indeed huge. Why is this happening so often: /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/include/stdlib.h:257:4: warning: ISO C does not support the ‘_Float64x’ type [-Wpedantic] > However, some files seem to be installed. > > $ ls $HOME/pacman/usr/local/bin/ > pacman pacman-conf testpkg vercmp > > Thanks, > Amar >
> So the question then is, what is this resolving to? > checking for bash... > /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash > It needs to be bash >= 4.4.0, and we have a check which is supposed to > enforce this: > https://git.archlinux.org/pacman.git/tree/configure.ac?h=v5.2.1#n201 > What version is your bash program, and why might it be refusing to > recognize this bash syntax? The bash version is 5.0.7 $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash --version GNU bash, version 5.0.7(1)-release (x86_64-unknown-linux-gnu) > Why is this happening so often: > /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/include/stdlib.h:257:4: > warning: ISO C does not support the ‘_Float64x’ type [-Wpedantic] --pedantic is a GCC flag which causes every non-standard C to raise an error, even though it may be an available extension in GCC. And, -Wpedantic will warn about these deviations from the standard. Despite the errors and warnings, it appears that I have a working pacman. Thanks a lot, Eli. $ pacman --version .--. Pacman v5.2.1 - libalpm v12.0.1 / _.-' .-. .-. .-. Copyright (C) 2006-2019 Pacman Development Team \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet '--' This program may be freely redistributed under the terms of the GNU General Public License. Thanks, Amar
On 1/5/20 6:08 PM, nly@disroot.org wrote: >> So the question then is, what is this resolving to? >> checking for bash... >> /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash > >> It needs to be bash >= 4.4.0, and we have a check which is supposed to >> enforce this: >> https://git.archlinux.org/pacman.git/tree/configure.ac?h=v5.2.1#n201 >> What version is your bash program, and why might it be refusing to >> recognize this bash syntax? > > The bash version is 5.0.7 > > $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash --version > GNU bash, version 5.0.7(1)-release (x86_64-unknown-linux-gnu) Then I cannot understand why it is complaining here! Do you get the same error when you manually run this: $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash -O extglob -n ./scripts/libmakepkg/executable/checksum.sh >> Why is this happening so often: > >> /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/include/stdlib.h:257:4: >> warning: ISO C does not support the ‘_Float64x’ type [-Wpedantic] > > --pedantic is a GCC flag which causes every non-standard C to raise an > error, even though it may be an available extension in GCC. And, > -Wpedantic will warn about these deviations from the standard. Yeah... but the problem here is that you're generating pedantic warnings for lacking ISO C conformance in your libc headers, which is just plain useless. Might as well disable all warnings. > Despite the errors and warnings, it appears that I have a working > pacman. Thanks a lot, Eli. If you only build lib/libalpm/ and src/pacman/ then sure. Do you need a working makepkg too, though? > $ pacman --version > > .--. Pacman v5.2.1 - libalpm v12.0.1 > / _.-' .-. .-. .-. Copyright (C) 2006-2019 Pacman Development Team > \ '-. '-' '-' '-' Copyright (C) 2002-2006 Judd Vinet > '--' > This program may be freely redistributed under > the terms of the GNU General Public License. > > Thanks, > Amar >
> Yeah... but the problem here is that you're generating pedantic warnings > for lacking ISO C conformance in your libc headers, which is just plain > useless. Might as well disable all warnings. I see. I set `-Wno-pedantic' flags in `configure.ac'. This should shorten the log a whole lot. Thanks for the patience. Patch Attached. > Then I cannot understand why it is complaining here! Do you get the same > error when you manually run this: > $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash -O > extglob -n ./scripts/libmakepkg/executable/checksum.sh $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash -O extglob -n ./scripts/libmakepkg/executable/checksum.sh yields nothing. Unawares, I was using a different shell in my config. The issue was my environment, `~/.emacs' config: (setq explicit-shell-file-name "gash" explicit-gash-args nil) I did expect make to use `bash' explicitly instead of using my `gash' shell. Now, using bash as shell, the build log is clean and error-free. log: http://nly.info.tm:9001/log/pacman3 > If you only build lib/libalpm/ and src/pacman/ then sure. Do you need a > working makepkg too, though? I do. After fixing the above mentioned issues, makepkg is also built. $ ls ~/pacman/usr/local/bin/ makepkg pacman pacman-db-upgrade repo-add repo-remove vercmp makepkg-template pacman-conf pacman-key repo-elephant testpkg Thanks, Amar
On 1/5/20 7:25 PM, nly@disroot.org wrote: >> Yeah... but the problem here is that you're generating pedantic warnings >> for lacking ISO C conformance in your libc headers, which is just plain >> useless. Might as well disable all warnings. > > I see. I set `-Wno-pedantic' flags in `configure.ac'. This should > shorten the log a whole lot. Thanks for the patience. Hmm, but we don't set -Wpedantic in the first place. Is guix doing that? >> Then I cannot understand why it is complaining here! Do you get the same >> error when you manually run this: >> $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash -O >> extglob -n ./scripts/libmakepkg/executable/checksum.sh > > $ /gnu/store/whkq7f2d702hqnrdd2cqskqxdx267283-profile/bin/bash -O extglob -n > ./scripts/libmakepkg/executable/checksum.sh > > yields nothing. > > Unawares, I was using a different shell in my config. > > The issue was my environment, `~/.emacs' config: > (setq explicit-shell-file-name "gash" > explicit-gash-args nil) > > I did expect make to use `bash' explicitly instead of using my `gash' > shell. Now, using bash as shell, the build log is clean and error-free. I've never heard of gash before, but... https://savannah.nongnu.org/projects/gash/ "Gash is designed to bootstrap Bash as part of the Guix bootstrap process." This makes me nervous that it may be internally doing Magic Things™ to advertise itself as bash in some way that the configure script or Makefile gets fooled by. If you can figure out just why this happened, and/or a way to reliably ensure bash itself is detected instead of gash, then we might be able to fine-tune our detection algorithm. > log: http://nly.info.tm:9001/log/pacman3 > >> If you only build lib/libalpm/ and src/pacman/ then sure. Do you need a >> working makepkg too, though? > > I do. After fixing the above mentioned issues, makepkg is also > built. Great! > $ ls ~/pacman/usr/local/bin/ > makepkg pacman pacman-db-upgrade repo-add repo-remove vercmp > makepkg-template pacman-conf pacman-key repo-elephant testpkg > > Thanks, > Amar >
> Hmm, but we don't set -Wpedantic in the first place. Is guix doing > that? beats me. > This makes me nervous that it may be internally doing Magic Things™ to > advertise itself as bash in some way that the configure script or > Makefile gets fooled by. > If you can figure out just why this happened, and/or a way to reliably > ensure bash itself is detected instead of gash, then we might be able to > fine-tune our detection algorithm. Checking for BASH_VERSION can distinguish between Gash, where it's unset and Bash where it's set to the version string. $ gash $ echo $BASH_VERSION $ bash $ echo $BASH_VERSION 5.0.7(1)-release I can reproduce the error by entering the gash shell before building. libmakepkg/executable/checksum.sh: line 33: syntax error near unexpected token `<' libmakepkg/executable/checksum.sh: line 33: ` mapfile -t integlist < <(get_integlist)' make[3]: *** [Makefile:994: libmakepkg/executable/checksum.sh] Error 2 Log: http://nly.info.tm/log/pacman4 `configure.ac' and `scripts/Makefile.am' look fine to me. I wonder what's causing gash to be used. Thanks, Amar -------------------------------------------------------------------------------- ---- `configure.ac'---- AC_PATH_PROGS([BASH_SHELL], [bash bash4], [false]) ----`scripts/Makefile.am'---- @$(BASH_SHELL) -O extglob -n $@
diff --git a/configure.ac b/configure.ac index e59f82e9..9db39232 100644 --- a/configure.ac +++ b/configure.ac @@ -228,6 +228,7 @@ PKG_CHECK_VAR(bashcompdir, [bash-completion], [completionsdir], , PKG_CHECK_MODULES(LIBARCHIVE, [libarchive >= 3.0.0], , AC_MSG_ERROR([*** libarchive >= 3.0.0 is needed to compile pacman!])) +m4_pattern_forbid([^AX_COMPARE_VERSION$]) # Check file for seccomp if test "x$with_file_seccomp" = "xauto"; then file_version="$(file --version| sed -n 's/^file-\(.*\)/\1/p')"
Forbid the AX_COMPARE_VERSION macro from being found in the output configure script. If autoconf-archive is not installed when autoreconf is run, the following error message is emitted: configure.ac:231: error: possibly undefined macro: AX_COMPARE_VERSION If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- Actually, I think we can catch this error in a more visible way! At least now people will be able to tell that the autoreconf was borked and "it's missing something", and "possibly undefined macro" has better googleability than: (dash) ./configure: Syntax error: word unexpected (expecting ")") configure.ac | 1 + 1 file changed, 1 insertion(+)