bug#61086: [3.0.9] Wrong ‘AR’ value in ‘--enable-lto’ builds

[Ludovic Courtès]

In 3.0.9, ‘configure --enable-lto’ goes like this:

--8<---------------cut here---------------start------------->8---
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ar... (cached) ar
checking for ranlib... ranlib
checking for gcc option to enable large file support... none needed
configure: autobuild project... GNU Guile
configure: autobuild revision... 3.0.9
./configure: line 8292: hostname: command not found
configure: autobuild timestamp... 20230126T203648Z
checking whether the compiler supports -flto... yes
checking for lto-specific prefix for ar, nm, objcopy, ranlib... gcc
checking for gcc-nm... gcc-nm
checking for gcc-objcopy... no
checking for objcopy... objcopy
checking compiler's C standard... c11
--8<---------------cut here---------------end--------------->8---

Notice that there’s no line for ‘gcc-ar’.  ‘configure.ac’ reads this:

--8<---------------cut here---------------start------------->8---
    AC_MSG_CHECKING([for lto-specific prefix for ar, nm, objcopy, ranlib])
    if test "$GCC" = yes; then
       TOOLCHAIN_PREFIX=gcc
    else
       # Assuming LLVM if not GCC.  Probably won't hurt.
       TOOLCHAIN_PREFIX=llvm
    fi
    AC_MSG_RESULT([$TOOLCHAIN_PREFIX])
    AC_CHECK_TOOLS([AR], [$TOOLCHAIN_PREFIX-ar ar])
    AC_CHECK_TOOLS([NM], [$TOOLCHAIN_PREFIX-nm nm])
    AC_CHECK_TOOLS([OBJCOPY], [$TOOLCHAIN_PREFIX-objcopy objcopy])
    AC_CHECK_TOOLS([RANLIB], [$TOOLCHAIN_PREFIX-ranlib ranlib])
--8<---------------cut here---------------end--------------->8---

… but here the ‘AR’ and ‘RANLIB’ bits are omitted, because their value
were already computed earlier.

Contrast with 3.0.8, where the LTO tool search happened before:

--8<---------------cut here---------------start------------->8---
checking dependency style of gcc... gcc3
checking whether the compiler supports -flto... yes
checking for lto-specific prefix for ar, nm, objcopy, ranlib... gcc
checking for gcc-ar... gcc-ar
checking for gcc-nm... gcc-nm
checking for gcc-objcopy... no
checking for objcopy... objcopy
checking for gcc-ranlib... gcc-ranlib
checking how to enable C11 support... -std=gnu11

[...]

checking for Minix Amsterdam compiler... no
checking the archiver (gcc-ar) interface... ar
checking for ar... (cached) gcc-ar
checking for special C compiler options needed for large files... no
--8<---------------cut here---------------end--------------->8---

The effect is that 3.0.9 fails to build when doing a static build as
with (@ (gnu packages make-bootstrap) %guile-static-3.0) in Guix:

--8<---------------cut here---------------start------------->8---
  CCLD     libguile-3.0.la
ar: libguile_3.0_la-alist.o: plugin needed to handle lto object
ranlib: .libs/libguile-3.0.a(libguile_3.0_la-alist.o): plugin needed to handle 
lto object
  CCLD     guile
ld: /tmp/guix-build-guile-static-3.0.9.drv-0/ccQkracO.ltrans0.ltrans.o: in 
function `inner_main':
/tmp/guix-build-guile-static-3.0.9.drv-0/guile-3.0.9/libguile/guile.c:50: 
undefined reference to `scm_shell'
ld: /tmp/guix-build-guile-static-3.0.9.drv-0/ccQkracO.ltrans0.ltrans.o: in 
function `main':
/tmp/guix-build-guile-static-3.0.9.drv-0/guile-3.0.9/libguile/guile.c:94: 
undefined reference to `scm_boot_guile'
collect2: error: ld returned 1 exit status
--8<---------------cut here---------------end--------------->8---

(Notice the “plugin needed” message, due to the fact that we’re using
‘ranlib’ instead of ‘gcc-ranlib’.)

This may be a side effect of aeb22f486139f457ae7fc44c2d931312aaae52d8,
which moved ‘gl_EARLY’ earlier (not surprisingly).

Ludo’.