From: FX <fxcoudert@gmail.com>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Cc: David Starner <prosfilaes@gmail.com>,
Andrew Haley <aph@redhat.com>, Bruce Korb <bruce.korb@gmail.com>,
jwakely.gcc@gmail.com,
Michael Veksler <mveksler@tx.technion.ac.il>
Subject: Re: fatal error: gnu/stubs-32.h: No such file
Date: Tue, 30 Jul 2013 13:54:00 -0000 [thread overview]
Message-ID: <58F1AD55-AFB6-4BE9-A112-34B8386373C0@gmail.com> (raw)
In-Reply-To: <51F79E41.9040302@tx.technion.ac.il>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
> If --enable-multilib or --disable-multilib are passed then things
> are performed as today, more or less. If these flags are not
> explicitly given then gcc has to do something different
This sounds reasonable. We could have a specific check, with the following cumulative conditions (to make it as unobtrusive as possible for current users). If:
1. we build a native compiler
2. on x86_64-linux (and possible other x86_64 targets whose maintainers want to opt in)
3. and neither --enable-multilib nor --disable-multilib were passed
then:
a. we check that the native compiler can handle 32-bit, by compiling a test executable with the "-m32" option
b. if we fail, we error out of the configure process, indicating that this can be overriden with --{enable,disable}-multilib
I suspect this might catch (at configure time) the large majority of users who currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while being invisible to a large majority of the power users.
Question: what are the pitfalls of the test proposed above? are there typical use cases that I have not thought of, and that would trigger this check?
FX
PS: I attach a tentative patch implementing such as check in configure.ac.
[-- Attachment #2: 64bit_configure_patch.txt --]
[-- Type: text/plain, Size: 1270 bytes --]
Index: configure.ac
===================================================================
--- configure.ac (revision 201292)
+++ configure.ac (working copy)
@@ -2861,6 +2861,26 @@ case "${target}" in
;;
esac
+# Special user-friendly check for native x86_64-linux build, if
+# multilib is not explicitly enabled.
+case "$target:$have_compiler:$host:$target:$enable_multilib" in
+ x86_64-*linux*:yes:$build:$build:)
+ # Make sure we have a developement environment that handles 32-bit
+ dev64=no
+ echo "int main () { return 0; }" > conftest.c
+ ${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
+ if test $? = 0 ; then
+ if test -s conftest || test -s conftest.exe ; then
+ dev64=yes
+ fi
+ fi
+ rm -f conftest*
+ if test x${dev64} != xyes ; then
+ AC_MSG_ERROR([I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
+ fi
+ ;;
+esac
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs="--enable-multilib ${target_configargs}"
next prev parent reply other threads:[~2013-07-30 13:54 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-28 13:24 FX
2013-07-29 13:06 ` FX
2013-07-29 13:23 ` Andrew Haley
2013-07-29 13:55 ` Bruce Korb
2013-07-29 14:20 ` Andrew Haley
2013-07-30 4:28 ` David Starner
2013-07-30 4:50 ` David Starner
2013-07-30 4:58 ` Andrew Pinski
2013-07-30 13:13 ` David Starner
2013-07-30 7:56 ` Andrew Haley
2013-07-30 12:52 ` David Starner
2013-07-30 14:34 ` Andrew Haley
2013-07-30 11:06 ` Michael Veksler
2013-07-30 13:54 ` FX [this message]
2013-07-31 19:44 ` Matthias Klose
2013-07-31 20:14 ` Jonathan Wakely
2013-07-31 20:23 ` Russ Allbery
-- strict thread matches above, loose matches on Subject: below --
2013-07-24 0:48 David Starner
2013-07-24 8:17 ` Andrew Haley
2013-07-24 8:36 ` Florian Weimer
2013-07-24 8:39 ` Andrew Haley
2013-07-24 9:05 ` Florian Weimer
2013-07-24 9:18 ` Andrew Haley
2013-07-24 10:32 ` David Starner
2013-07-24 11:14 ` Andrew Haley
2013-07-24 12:26 ` David Starner
2013-07-24 13:44 ` Andrew Haley
2013-07-24 12:37 ` Gabriel Dos Reis
2013-07-24 13:45 ` Andrew Haley
2013-07-24 15:38 ` Gabriel Dos Reis
2013-07-24 15:50 ` Andrew Haley
2013-07-24 22:52 ` David Starner
2013-07-25 8:17 ` Andrew Haley
2013-07-26 0:00 ` David Starner
2013-07-26 9:01 ` Andrew Haley
2013-07-27 13:56 ` David Starner
2013-07-27 19:23 ` Jonathan Wakely
2013-07-27 22:54 ` Gabriel Dos Reis
2013-07-27 23:10 ` David Starner
2013-07-27 23:53 ` Gabriel Dos Reis
2013-07-06 15:41 Bruce Korb
2013-07-06 16:02 ` Andrew Haley
2013-07-06 16:09 ` Bruce Korb
2013-07-06 18:53 ` Andreas Schwab
2013-07-07 14:00 ` Bruce Korb
2013-07-07 17:44 ` Jonathan Wakely
2013-07-07 20:33 ` Gabriel Dos Reis
2013-07-07 23:02 ` Jonathan Wakely
2013-07-08 5:17 ` Gabriel Dos Reis
2013-07-08 5:19 ` Andrew Pinski
2013-07-08 5:55 ` Gabriel Dos Reis
2013-07-08 5:59 ` Andrew Pinski
2013-07-08 6:33 ` Gabriel Dos Reis
2013-07-08 8:43 ` Andrew Haley
2013-07-08 9:00 ` Gabriel Dos Reis
2013-07-08 7:13 ` Jakub Jelinek
2013-07-08 7:18 ` Gabriel Dos Reis
2013-08-14 8:53 ` Alexandre Oliva
2013-08-14 16:39 ` Andreas Schwab
2013-08-14 19:01 ` Gabriel Dos Reis
2013-07-08 15:11 ` Bruce Korb
2013-07-08 15:24 ` Jakub Jelinek
2013-07-08 15:39 ` Bruce Korb
2013-07-08 17:27 ` Jonathan Wakely
2013-07-08 18:08 ` Bruce Korb
2013-07-16 9:40 ` Florian Weimer
2013-07-16 12:46 ` Gabriel Dos Reis
2013-07-16 13:24 ` Jonathan Wakely
2013-07-16 14:26 ` Andrew Pinski
2013-07-16 14:35 ` Bruce Korb
2013-07-16 15:04 ` Gabriel Dos Reis
2013-07-16 15:11 ` Jonathan Wakely
2013-07-16 15:13 ` Gabriel Dos Reis
2013-07-16 15:40 ` Bruce Korb
2013-07-08 8:42 ` Andrew Haley
2013-07-07 20:31 ` Gabriel Dos Reis
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58F1AD55-AFB6-4BE9-A112-34B8386373C0@gmail.com \
--to=fxcoudert@gmail.com \
--cc=aph@redhat.com \
--cc=bruce.korb@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=mveksler@tx.technion.ac.il \
--cc=prosfilaes@gmail.com \
/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).