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

> As a consensual first step toward addressing this issue, I suggest the following patch to the doc. I hope it is clear enough, but suggestions are obviously welcome. (I haven't even compiled the docs with it, as I'm on my laptop with little battery.)

Given that I received no feedback, I'd like to submit this doc patch formally. Tested by doing "make info html pdf".
OK to commit to trunk? What about other active release branches?

FX

On 07/29/2013 02:06 PM, FX wrote:
> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
> +either:
> +
> +@itemize @bullet
> +@item having 32-bit libc developer package properly installed (the exact
> +name of the package depends on your distro); otherwise, you may encounter an
> +error such as @samp{fatal error: gnu/stubs-32.h: No such file}
> +@item building GCC as a 64-bit only compiler, by configuring with the
> +option @option{--disable-multilib}
> +@end itemize

Looks good.

This should be

"Make sure you either have the 32-bit libc developer package properly
installed (the exact name of the package depends on your distro) or
you must build GCC as a 64-bit-only compiler by configuring with the
--disable-multilib option.  Otherwise, you may encounter an
error such as @samp{fatal error: gnu/stubs-32.h: No such file}

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.

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.

Am 29.07.2013 15:06, schrieb FX:
>> As a consensual first step toward addressing this issue, I suggest the following patch to the doc. I hope it is clear enough, but suggestions are obviously welcome. (I haven't even compiled the docs with it, as I'm on my laptop with little battery.)
> 
> Given that I received no feedback, I'd like to submit this doc patch formally. Tested by doing "make info html pdf".
> OK to commit to trunk? What about other active release branches?

if you mention distribution specific packages, please add the ones needed for
some distributions. For Debian/Ubuntu this would be g++-multilib if the
architecture is multilib'ed, g++ otherwise.

  Matthias

On 31 July 2013 20:44, Matthias Klose wrote:
> if you mention distribution specific packages, please add the ones needed for
> some distributions. For Debian/Ubuntu this would be g++-multilib if the
> architecture is multilib'ed, g++ otherwise.

That's not the package that provides gnu/stubs-32.h, is it?  I thought
it was something like libc6-dev-i386?  Please correct
http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h if I'm wrong.

Jonathan Wakely <jwakely.gcc@gmail.com> writes:
> On 31 July 2013 20:44, Matthias Klose wrote:

>> if you mention distribution specific packages, please add the ones needed for
>> some distributions. For Debian/Ubuntu this would be g++-multilib if the
>> architecture is multilib'ed, g++ otherwise.

> That's not the package that provides gnu/stubs-32.h, is it?  I thought
> it was something like libc6-dev-i386?  Please correct
> http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h if I'm wrong.

gcc-multilib and g++-multilib depend on all the various packages that you
need to have.  They will, among other things, install libc6-dev-i386.  For
example, on a current wheezy system, you will see the following dependency
chain:

    gcc-multilib -> gcc-4.7-multilib -> libc6-dev-i386

but also various other things like lib32gcc1.

It looks like this has not been applied, FX?

Were you waiting for further approval?  If so: okay with the change
proposed by Andrew.

Thanks,
Gerald

On Mon, 29 Jul 2013, Andrew Haley wrote:
> On 07/29/2013 02:06 PM, FX wrote:
>> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
>> +either:
>> +
>> +@itemize @bullet
>> +@item having 32-bit libc developer package properly installed (the exact
>> +name of the package depends on your distro); otherwise, you may encounter an
>> +error such as @samp{fatal error: gnu/stubs-32.h: No such file}
>> +@item building GCC as a 64-bit only compiler, by configuring with the
>> +option @option{--disable-multilib}
>> +@end itemize
> 
> Looks good.
> 
> This should be
> 
> "Make sure you either have the 32-bit libc developer package properly
> installed (the exact name of the package depends on your distro) or
> you must build GCC as a 64-bit-only compiler by configuring with the
> --disable-multilib option.  Otherwise, you may encounter an
> error such as @samp{fatal error: gnu/stubs-32.h: No such file}

> Were you waiting for further approval?  If so: okay with the change
> proposed by Andrew.

Thanks, committed as rev. 205802 with Andrew’s change.

FX