[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AX_PROG_CC_FOR_BUILD / CC_FOR_BUILD and --build= interaction

From: Sergei Trofimovich
Subject: AX_PROG_CC_FOR_BUILD / CC_FOR_BUILD and --build= interaction
Date: Sun, 7 Jun 2020 12:44:55 +0100

Hello autoconf-archive-maintainers@!


  `AX_PROG_CC_FOR_BUILD` macro never considers tuple-prefixed
  tools for `BUILD` even if `--build=BUILD` was passed explicitly as
  a ./configure parameter.

  Should it? I think it should.

More words.

Gentoo explores the ways to catch cases when cross-compilation
uses wrong compiler by accident.

Gentoo builds packages always specifying `--build/--host/--target`:
    $ ./configure --build=${CBUILD} --host=${CHOST} --target=${CTARGET}
    $ make

and assumes according prefixed tools are used. Specifically, for `gcc` tool
as an example:
    ${CBUILD}-gcc (or gcc as a fallback)
    ${CHOST}-gcc (or gcc as a fallback)
    ${CTARGET}-gcc (or gcc as a fallback)

Macros like `AC_CHECK_TOOL` / `AC_CHECK_TARGET_TOOL` do the
right thing by default.

To make sure 'gcc' does not get called by accident Gentoo has a mode to
provide only tuple-prefixed tools, namely:
    ${CBUILD}-gcc (no gcc fallback)
    ${CHOST}-gcc (no gcc fallback either)

That way when package is built it's very clear from the build log when
some tool gets called with incorrect tuple. No implicit fallback happens.

For native builds `CBUILD` is `CHOST`. `./configure` is still called with all
the parameters to steer `./configure` to use tuple-prefixed tools:
    # native
    ./configure --build=${CBUILD} --host=${CBUILD} --target=${CBUILD}.

Now `AX_PROG_CC_FOR_BUILD` macro stands out. In this mode
`AX_PROG_CC_FOR_BUILD` does not attempt to lookup `${CBUILD}-gcc`
and just fails. Full example:

$ gcc -v
bash: gcc: command not found

$ x86_64-pc-linux-gnu-gcc -v
Target: x86_64-pc-linux-gnu
Configured with: .../configure --host=x86_64-pc-linux-gnu 
--build=x86_64-pc-linux-gnu ...

$ cat
    dnl for --host=
    dnl for --build=
    # This works, but it's too simplistic, just sets 'CC_FOR_BUILD=$(CC)'
    # Why does this not resolve CC to ${build}-gcc?

$ touch

$ mkdir -p m4 && aclocal --install && autoreconf -vif && ./configure 
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking whether x86_64-pc-linux-gnu-gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of x86_64-pc-linux-gnu-gcc... none
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/tmp/w':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

Note: x86_64-pc-linux-gnu-gcc is never considered here
and user always has to specify manually:

WDYT of tweaking ax_prog_cc_for_build.m4 to change
AX_PROG_CC_FOR_BUILD to also consider tuple-prefixed tools?

That way user would not have to pass CC_FOR_BUILD for case
when native tools are all tuple-prefixed.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]