[3.0.9] Wrong ‘AR’ value in ‘--enable-lto’ builds

  • Open
  • quality assurance status badge
Details
One participant
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 26 Jan 2023 21:50
(address . bug-guile@gnu.org)
875yctnhps.fsf@inria.fr
In 3.0.9, ‘configure --enable-lto’ goes like this:

Toggle snippet (17 lines)
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

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

Toggle snippet (14 lines)
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])

… 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:

Toggle snippet (18 lines)
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

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:

Toggle snippet (11 lines)
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

(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’.
?