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: Andrew Haley <aph at redhat dot com>
- To: Bruce Korb <bruce dot korb at gmail 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 15:19:52 +0100
- 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> <CAKRnqNKC=3a54YN+0kVNS8XQReey0etkFkUXC8F0M47K1F2=Sw at mail dot gmail dot com>
On 07/29/2013 02:55 PM, Bruce Korb wrote:
> 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.
It was "This is possible, but it's tricky, and it's really important
to get it right. We don't want a half-arsed patch."
>>> 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.
Oh dear.
> I translate it as, "I don't care if people are having trouble.
That's a mistranslation. It means that there are other criteria
beyond some people having trouble. Such as, we really want multilibs
to be built.
> 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*.
Yes! Yes! Yes!
Andrew.