This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fatal error: gnu/stubs-32.h: No such file


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]