This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fatal error: gnu/stubs-32.h: No such file
- From: Bruce Korb <bruce dot korb at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: FX <fxcoudert at gmail dot com>, gcc-patches at gcc dot gnu dot org, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "prosfilaes at gmail dot com" <prosfilaes at gmail dot com>, "jwakely dot gcc at gmail dot com" <jwakely dot gcc at gmail dot com>
- Date: Mon, 29 Jul 2013 06:55:28 -0700
- Subject: Re: fatal error: gnu/stubs-32.h: No such file
- References: <AA0A6252-438B-49DB-BDF6-0544CA1330BD at gmail dot com> <EDC179F1-805F-4D73-82AF-D4051A28A0E8 at gmail dot com> <51F66CA9 dot 4040803 at redhat dot com>
On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley <aph@redhat.com> wrote:
> There should be a better diagnostic.
If you remember, the start of this thread was:
> Why is it that configure worked but stubs-32.h was not found?
That is the correct thing to do. The reply, basically, was:
It's too hard.
OK, fine, the backup is to Google:
fatal error: gnu/stubs-32.h: No such file or directory
and have an early hit that tells you that you did not configure some 32 bit
developer package you had never heard of before. I guess that's easier
than configure tests or #error directives for the folks who do the
multi-lib stuff.
> > But we know people are running into this issue and reporting it.
> Yes. But that on its own is not sufficient to change the default
That's a pretty obnoxious comment. I translate it as, "I don't care if
people are having trouble. It is a nuisance to me to do that and anyone
building GCC should already know they need <whateveritwas>-devel for
32 bits." I guess I can be obnoxious, too. But slightly more politely put:
> No, we aren't. We're disagreeing about whether it's acceptable to
> enable a feature by default that breaks the compiler build half way
> through with an obscure error message. Real systems need features that
> aren't enabled by default sometimes.
The fundamental issue, to me, is: What do you do when you cannot proceed?
I think you should detect the issue as *soon as practical* and then *ALWAYS*
emit a message that *TELLS THE USER WHAT TO DO*. This failure is
later than it could be and leaves the user hanging and twisting in the wind.
Not good.