On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley <a...@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.