On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley <[email protected]> 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.
