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

[Gabriel Dos Reis <gdr@integrable-solutions.net>]

On Mon, Jul 8, 2013 at 12:59 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Sun, Jul 7, 2013 at 10:55 PM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Mon, Jul 8, 2013 at 12:19 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>>> On Sun, Jul 7, 2013 at 10:17 PM, Gabriel Dos Reis
>>> <gdr@integrable-solutions.net> wrote:
>>>> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>>> On 7 July 2013 21:33, Gabriel Dos Reis wrote:
>>>>>> How about not enabling multi lib build by default on targets we now that
>>>>>> will fail anyway?  I have the suspicion this problem is unique to openSUSE,
>>>>>> so we can take care of that.
>>>>>
>>>>> I'm pretty sure I've seen it happen with RHEL and Fedora, and Ubuntu
>>>>> users have asked about the same thing on the gcc-help list.
>>>>
>>>> Ha, if it is that spread then we might have even more reasons to
>>>> have it work more generally, for example, by disabling multilib by default.
>>>> I think the situation we are in now is very different from the situation
>>>> we were in more than a decade ago.
>>>
>>> I think disable multilib by default is a mistake and is a broken
>>> choice for broken distros which don't install the 32bit development by
>>> default when you install the development part.
>>
>> Why do you think it is a broken choice?
>>
>> Personally, I don't see anything broken with that.  The world we are
>> in today is very different from a decade ago.  More than a decade ago,
>> a multilib build by default -probably- made sense; I don't see that today.
>
> Maybe on x86 it does not make sense (until x32 comes into play) but

x86 constitutes a large share of GCC community.

> for other targets like MIPS64 or soon AARCH64 it does make sense
> because the they both have a 32bit ABI which sites over the 64bit ISA.

In that case enable multilib by default for those targets for which it makes
sense by default and you know for sure it won't result into a build
failure, instead
of the reverse situation of "well, if it blows, it blows; good luck,
we are crossing
our fingers for you."

> I think the problem is still in the distros rather than GCC.

I strongly disagree.  We (GCC) are at fault here.  We implicitly
enable a feature at configure time without knowing its builds
will succeed (despite having repeated reports that it does often
fail) without much input from the builder (who might be ignorant of
real reason of failures.)  Usually we do the opposite.

-- Gaby