Invalid configuration: machine not recognized (x86_64 Alpine Linux in Docker)

[rsms]

Attempting build in docker vm alpine:3.12, make fails relatively early with:

checking build system type... Invalid configuration `/root/build': machine `/root/build' not recognized

It appears as somehow dirname $PWD is being used for --build=/root/build --host=/root/build, which isn't right.

I've also tried passing HOST to make (make HOST=x86_64-linux-gnu) which that yields a different error: checking for C compiler... ../src_musl/configure: cannot find a C compiler

Note that gcc -print-multiarch does not print anything (bug in Alpine Linux's GCC package?)

Repro:

$ uname -a
Linux 1f6f5c9f6d99 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020 x86_64 Linux
$ apk update && apk add --no-cache \
  tar wget curl ca-certificates \
  make linux-headers flex bison patch rsync \
  findutils diffutils xz gcc g++ perl \
  bash git nano
$ mkdir /root/build
$ cd /root/build
$ git clone https://github.com/richfelker/musl-cross-make.git
$ cd musl-cross-make
$ git rev-parse HEAD
b12ded507831d0cac2dabd869aef14f3822a8770
$ sed -E 's/# (TARGET = x86_64-linux)/\1/' config.mak.dist > config.mak
$ make

End of output from make:

...
printf >build/local/x86_64-linux-musl/config.mak '%s\n' \
"TARGET = x86_64-linux-musl" \
"HOST = " \
"MUSL_SRCDIR = ../../../musl-1.2.1" \
"GCC_SRCDIR = ../../../gcc-9.2.0" \
"BINUTILS_SRCDIR = ../../../binutils-2.33.1" \
"GMP_SRCDIR = ../../../gmp-6.1.2" \
"MPC_SRCDIR = ../../../mpc-1.1.0" \
"MPFR_SRCDIR = ../../../mpfr-4.0.2" \
 \
"LINUX_SRCDIR = ../../../linux-5.8.5" \
"-include ../../../config.mak"
cd build/local/x86_64-linux-musl && make all
make[1]: Entering directory '/root/build/musl-cross-make/build/local/x86_64-linux-musl'
mkdir -p obj_musl
ln -sf ../../../musl-1.2.1 src_musl
mkdir -p obj_gcc
ln -sf ../../../gcc-9.2.0 src_gcc_base
ln -sf "../../../gmp-6.1.2" src_gmp
ln -sf "../../../mpc-1.1.0" src_mpc
ln -sf "../../../mpfr-4.0.2" src_mpfr
rm -rf src_gcc src_gcc.tmp
mkdir src_gcc.tmp
cd src_gcc.tmp && ln -sf ../src_gcc_base/* .
cd src_gcc.tmp && ln -sf ../src_gmp gmp
cd src_gcc.tmp && ln -sf ../src_mpc mpc
cd src_gcc.tmp && ln -sf ../src_mpfr mpfr
mv src_gcc.tmp src_gcc
mkdir -p obj_binutils
ln -sf ../../../binutils-2.33.1 src_binutils
cd obj_binutils && ../src_binutils/configure --disable-separate-code    --disable-werror --target=x86_64-linux-musl --prefix= --libdir=/lib --disable-multilib --with-sysroot=/x86_64-linux-musl --enable-deterministic-archives --build=/root/build --host=/root/build
checking build system type... Invalid configuration `/root/build': machine `/root/build' not recognized
configure: error: /bin/sh ../src_binutils/config.sub /root/build failed
make[1]: *** [Makefile:210: obj_binutils/.lc_configured] Error 1
make[1]: Leaving directory '/root/build/musl-cross-make/build/local/x86_64-linux-musl'
make: *** [Makefile:182: all] Error 2
$

[rsms]

I tried using a prebuilt gcc from https://musl.cc/#binaries instead of gcc from Alpine and that fails in the same way.

[richfelker]

Are you using a weird shell or shell config that affects non-interactive shells? I'm not sure where this is coming from but it looks like it might be from an expansion of $(shell ...) and the GNU make documentation is not clear on whether it always uses the standard shell or honors your $SHELL which might be a misbehaving shell of some sort (e.g. printing output as part of the cd command).

[rsms]

I'm just running the Alpine docker image with bash from it's apk package manager.

However I think I've found the culprit: I have BUILD=/root/build set in my environment (used by a few other unrelated scripts.) It's probably so that the build system picks that up. I don't see BUILD used in the project's top-level Makefile or config.mak but it's likely so that it's used from env in some other script and/or Makefile.

I just tried this out: (with a clean checkout of musl-cross-make and clean install of gcc)

unset BUILD
make

Success!

Ideas: The makefile could check for environment variables known to affect the build and warn the user about any that are not "officially" part of musl-cross-make.

Alternatively you could do something like this in an early script, to clean the env from anything but "official" variables:

[ -z "$__CLEAN_ENV" ] && exec env -i __CLEAN_ENV=1 \
  HOME="$HOME" \
  PATH="$PATH" \
  TARGET="$TARGET" \
  BINUTILS_VER="$BINUTILS_VER" \
  DL_CMD="$DL_CMD" \
  "$0" "$@"

Thank you for the quick response!

[richfelker]

It's intended that you can control these variables from the command line or environment, so scrubbing them would be breaking.

[rsms]

Got it. I wonder if documenting the "BUILD" variable then would help?

[richfelker]

Yeah, I was just thinking the same - we should probably document the env/make vars that are used.

[rsms]

:-)