[pacman-dev] [Build-Requirement] In configure.ac 'File3.8' with Seccomp is required.
Steps: # Checkout source git clone <pacman-git> cd pacman git checkout v5.2.1 # Build <setup the build env> autoreconf -vif && ./configure --> Fail configure fails to find the latest versoin, 3.8, of `file'. This version 3.8 of `file' is not even available in the official Arch packages. Is it possible to build with an earlier version of `file'? File version 3.8 was released about a month ago. thanks, Amar
On 1/5/20 2:46 PM, Amar M. Singh wrote:
pacman's configure.ac does not require file 5.38 to be installed. It merely checks that file of some version is installed, and then sets an option depending on whether the version is at least 5.38 Can you post the exact failure message you are seeing? -- Eli Schwartz Bug Wrangler and Trusted User
Thanks for the clarification. The error: ./configure: line 11708: syntax error near unexpected token `$file_version,' ./configure: line 11708: ` AX_COMPARE_VERSION($file_version, ge, 5.38, with_file_seccomp=yes)' Attached full log. Thanks, Amar
On 1/5/20 3:20 PM, nly@disroot.org wrote:
Thanks. This is a syntax error, meaning that the AX_COMPARE_VERSION() m4 macro was not available when you ran autoreconf, so the configure script was incorrectly generated. The shell errored out when trying to execute the m4 macro as an sh command. In order to run autoreconf, you need to have autoconf-archive installed. As per https://www.archlinux.org/pacman/#_releases you can get dist tarballs for any version of pacman, here: https://sources.archlinux.org/other/pacman/ These are PGP-signed and come with autoreconf already run, so you don't need to run it yourself -- just go straight to ./configure; make; make install. -- Eli Schwartz Bug Wrangler and Trusted User
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(+) 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')" -- 2.24.1
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:
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?
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]
-- Eli Schwartz Bug Wrangler and Trusted User
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:
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
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?
-- Eli Schwartz Bug Wrangler and Trusted User
I see. I set `-Wno-pedantic' flags in `configure.ac'. This should shorten the log a whole lot. Thanks for the patience. Patch Attached.
$ /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:
Hmm, but we don't set -Wpedantic in the first place. Is guix doing that?
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.
Great!
-- Eli Schwartz Bug Wrangler and Trusted User
Hmm, but we don't set -Wpedantic in the first place. Is guix doing that?
beats me.
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 $@
participants (3)
-
Allan McRae
-
Eli Schwartz
-
nly＠disroot.org