From: "Ludovic Courtès" <ludo@gnu.org>
To: 61086@debbugs.gnu.org
Subject: bug#61086: [3.0.9] Wrong ‘AR’ value in ‘--enable-lto’ builds
Date: Thu, 26 Jan 2023 21:50:23 +0100 [thread overview]
Message-ID: <875yctnhps.fsf@inria.fr> (raw)
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’.
reply other threads:[~2023-01-26 20:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875yctnhps.fsf@inria.fr \
--to=ludo@gnu.org \
--cc=61086@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).