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

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

[Bruce Korb]

> make[5]: Entering directory `/u/gnu/proj/gcc-bld/x86_64-unknown-linux-gnu/32/libgcc'
> # If this is the top-level multilib, build all the other
> # multilibs.
> DEFINES='' HEADERS='../../../../gcc-svn/libgcc/config/i386/value-unwind.h' \
>         ../../../../gcc-svn/libgcc/mkheader.sh > tmp-libgcc_tm.h
> /bin/sh ../../../../gcc-svn/libgcc/../move-if-change tmp-libgcc_tm.h libgcc_tm.h
> echo timestamp > libgcc_tm.stamp
> /u/gnu/proj/gcc-bld/./gcc/xgcc -B/u/gnu/proj/gcc-bld/./gcc/ -B/u/gnu/inst/x86_64-unknown-linux-gnu/bin/ -B/u/gnu/inst/x86_64-unknown-linux-gnu/lib/ -isystem /u/gnu/inst/x86_64-unknown-linux-gnu/include -isystem /u/gnu/inst/x86_64-unknown-linux-gnu/sys-include    -g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic -mlong-double-80 -I. -I. -I../../.././gcc -I../../../../gcc-svn/libgcc -I../../../../gcc-svn/libgcc/. -I../../../../gcc-svn/libgcc/../gcc -I../../../../gcc-svn/libgcc/../include -I../../../../gcc-svn/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-svn/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
> In file included from /usr/include/features.h:399:0,
>                  from /usr/include/stdio.h:27,
>                  from ../../../../gcc-svn/libgcc/../gcc/tsystem.h:87,
>                  from ../../../../gcc-svn/libgcc/libgcc2.c:27:
> /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
>  # include <gnu/stubs-32.h>
>                            ^
> compilation terminated.
> make[5]: *** [_muldi3.o] Error 1
> make[5]: Leaving directory `/u/gnu/proj/gcc-bld/x86_64-unknown-linux-gnu/32/libgcc'
> make[4]: *** [multi-do] Error 1

The above was preceded by:

> $ ../gcc-svn/configure --enable-languages=c,c++,java,objc,go --prefix=/u/gnu/inst
> configure: loading site script /usr/share/site/x86_64-unknown-linux-gnu
> checking build system type... x86_64-unknown-linux-gnu
> [...]
> checking for version 0.11 of ISL... no
>  'c++' language required by 'go' in stage 1; enabling
> The following languages will be built: c,c++,go,java,lto,objc
> *** This configuration is not supported in the following subdirectories:
>      gnattools target-libada target-libgfortran
>     (Any other directories should still work fine.)
> checking for default BUILD_CONFIG... bootstrap-debug
> checking for bison... bison -y
> [...]
> checking whether to enable maintainer-specific portions of Makefiles... no
> configure: creating ./config.status
> config.status: creating Makefile
> $ make

Why is it that configure worked but stubs-32.h was not found?
Googling leads me to:
> You're missing the 32 bit libc dev package:

but the configure step should detect that and object before
this otherwise obscure message comes up.  Since one has to find
and select this stuff from an extensive list of packages
every time there is a new distribution, it is easy to overlook....

Thanks!

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

[Andrew Haley]

On 07/06/2013 04:41 PM, Bruce Korb wrote:
> Why is it that configure worked but stubs-32.h was not found?
> Googling leads me to:
>> > You're missing the 32 bit libc dev package:
> but the configure step should detect that

The trouble with making suggestions like this is that someone will ask
you for a patch.  Hint: getting this right for every corner case is
not easy.  Patches welcome.

> and object before this otherwise obscure message comes up.  Since
> one has to find and select this stuff from an extensive list of
> packages every time there is a new distribution, it is easy to
> overlook....

Or --disable-multilib.

Andrew.

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

[Bruce Korb]

On 07/06/13 09:02, Andrew Haley wrote:
> On 07/06/2013 04:41 PM, Bruce Korb wrote:
>> Why is it that configure worked but stubs-32.h was not found?
>> Googling leads me to:
>>>> You're missing the 32 bit libc dev package:
>> but the configure step should detect that
>
> The trouble with making suggestions like this is that someone will ask
> you for a patch.  Hint: getting this right for every corner case is
> not easy.  Patches welcome.

Time is finite for everyone.  If the owner of the code responsible
for needing "stubs-32.h" were to see the message, they would certainly
be in a better position than me to insert something into the configure
script.  Several hours of my researching the issue vs. asking
someone with the right knowledge for a few minutes....

> Or --disable-multilib.

Knowing that that is adequate would also take some hours of research.
So if you have the right knowledge, a few of your minutes would be
appreciated.  If you do not, please stop reading.  Thank you.

  - Bruce

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

[Andreas Schwab]

Bruce Korb <bruce.korb@gmail.com> writes:

> Why is it that configure worked but stubs-32.h was not found?

This is testing the host compiler which doesn't need that file.  You
need to build the target compiler before you can test it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Bruce Korb]

On 07/06/13 11:53, Andreas Schwab wrote:
> Bruce Korb <bruce.korb@gmail.com> writes:
>
>> Why is it that configure worked but stubs-32.h was not found?
>
> This is testing the host compiler which doesn't need that file.  You
> need to build the target compiler before you can test it.

Sorry, I'm still confused.  I had a fresh openSuSE distro and I
was trying to build GCC from SVN source.  If doing that requires
the installation of 32 bit development package, then I think I
am trying to say that configure should go look for the needed 32
bit dev package and complain.  I am hoping that the developer
responsible for the code trying to include the header would
fiddle the configure script.  I confess to trying to avoid that
kind of fiddling.

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

[Jonathan Wakely]

On 7 July 2013 15:00, Bruce Korb <bruce.korb@gmail.com> wrote:
> On 07/06/13 11:53, Andreas Schwab wrote:
>>
>> Bruce Korb <bruce.korb@gmail.com> writes:
>>
>>> Why is it that configure worked but stubs-32.h was not found?
>>
>>
>> This is testing the host compiler which doesn't need that file.  You
>> need to build the target compiler before you can test it.
>
>
> Sorry, I'm still confused.  I had a fresh openSuSE distro and I
> was trying to build GCC from SVN source.  If doing that requires
> the installation of 32 bit development package, then I think I
> am trying to say that configure should go look for the needed 32
> bit dev package and complain.  I am hoping that the developer
> responsible for the code trying to include the header would
> fiddle the configure script.  I confess to trying to avoid that
> kind of fiddling.

There is no code trying to include the header, GCC doesn't include it
directly, it is included by glibc's <features.h> which is included by
other headers GCC uses.

The point is, how do you test for "the needed 32 bit dev package"?
The only way is to try compiling a program as 32-bit, but that can
only be done by the target compiler once it's built, because the host
compiler might not be capable of 32-bit output.

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

[Gabriel Dos Reis]

On Sun, Jul 7, 2013 at 9:00 AM, Bruce Korb <bruce.korb@gmail.com> wrote:
> On 07/06/13 11:53, Andreas Schwab wrote:
>>
>> Bruce Korb <bruce.korb@gmail.com> writes:
>>
>>> Why is it that configure worked but stubs-32.h was not found?
>>
>>
>> This is testing the host compiler which doesn't need that file.  You
>> need to build the target compiler before you can test it.
>
>
> Sorry, I'm still confused.  I had a fresh openSuSE distro and I
> was trying to build GCC from SVN source.  If doing that requires
> the installation of 32 bit development package, then I think I
> am trying to say that configure should go look for the needed 32
> bit dev package and complain.  I am hoping that the developer
> responsible for the code trying to include the header would
> fiddle the configure script.  I confess to trying to avoid that
> kind of fiddling.

I have been having this problem since 2001 on SuSE or openSUSE.
For some reason, GCC's build machinery  does not want to
detect at configuration type that there is no stub-32.h file, therefore
there is absolutely no point in trying to do a multilib which would fail.
I have to provide explicitly --disable-multilib; like you, I think we
should not have to do that.

-- Gaby

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

[Gabriel Dos Reis]

On Sun, Jul 7, 2013 at 12:44 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 7 July 2013 15:00, Bruce Korb <bruce.korb@gmail.com> wrote:
>> On 07/06/13 11:53, Andreas Schwab wrote:
>>>
>>> Bruce Korb <bruce.korb@gmail.com> writes:
>>>
>>>> Why is it that configure worked but stubs-32.h was not found?
>>>
>>>
>>> This is testing the host compiler which doesn't need that file.  You
>>> need to build the target compiler before you can test it.
>>
>>
>> Sorry, I'm still confused.  I had a fresh openSuSE distro and I
>> was trying to build GCC from SVN source.  If doing that requires
>> the installation of 32 bit development package, then I think I
>> am trying to say that configure should go look for the needed 32
>> bit dev package and complain.  I am hoping that the developer
>> responsible for the code trying to include the header would
>> fiddle the configure script.  I confess to trying to avoid that
>> kind of fiddling.
>
> There is no code trying to include the header, GCC doesn't include it
> directly, it is included by glibc's <features.h> which is included by
> other headers GCC uses.
>
> The point is, how do you test for "the needed 32 bit dev package"?
> The only way is to try compiling a program as 32-bit, but that can
> only be done by the target compiler once it's built, because the host
> compiler might not be capable of 32-bit output.

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.

-- Gaby

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

[Jonathan Wakely]

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.

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

[Gabriel Dos Reis]

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.

-- Gaby

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

[Andrew Pinski]

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.

Thanks,
Andrew

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

[Gabriel Dos Reis]

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.

-- Gaby

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

[Andrew Pinski]

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
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.

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

Thanks,
Andrew Pinski

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

[Gabriel Dos Reis]

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

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

[Jakub Jelinek]

On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote:
> 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.

But having multilib enabled by default on x86_64 is simply very highly
desirable, checking that you have a (minimal, for gcc you pretty much only
need glibc and libgcc development stuff) 32-bit environment is just
one of the many items you need to check before you start building gcc.
You also need gmp, mpfr, mpc development (headers+libraries), flex, bison,
texinfo, ..., lots of this isn't installed by default.

	Jakub

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

[Gabriel Dos Reis]

On Mon, Jul 8, 2013 at 2:13 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote:
>> 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.
>
> But having multilib enabled by default on x86_64 is simply very highly
> desirable, checking that you have a (minimal, for gcc you pretty much only
> need glibc and libgcc development stuff) 32-bit environment is just
> one of the many items you need to check before you start building gcc.
> You also need gmp, mpfr, mpc development (headers+libraries), flex, bison,
> texinfo, ..., lots of this isn't installed by default.

But the situation is not the same.  These tools are checked at
configuration time, and the builder is let known in no uncertain terms
that something is missing.  If you don't have gmp or mfr installed,
configure will let you know, loudly complains, and won't budge until
you install the required tools.

The subject is very different.

-- Gaby

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

[Andrew Haley]

On 07/08/2013 06:17 AM, Gabriel Dos Reis 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.

That would, as they saying goes, be to throw the baby out with the
bathwater.

Andrew.

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

[Andrew Haley]

On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote:
> 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.) 

That's better than silently disable multilib builds so that the
user doesn't know until the build is complete.  It's better to
abort early.

Andrew.

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

[Gabriel Dos Reis]

On Mon, Jul 8, 2013 at 3:43 AM, Andrew Haley <aph@redhat.com> wrote:
> On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote:
>> 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.)
>
> That's better than silently disable multilib builds so that the
> user doesn't know until the build is complete.

I don't think this is what is being proposed.

>   It's better to abort early.

it is, as the saying goes, drowning the baby because we want to
keep the water.

-- Gaby


>
> Andrew.
>

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

[Bruce Korb]

Hi,

On Sun, Jul 7, 2013 at 10:19 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> 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.

If a distro does something that you consider wrong, you would have their many
clients suffer?  When there's a simple test to see if the platform can support
multilib?  That is not very friendly.  Not friendly at all.

> > 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.

Making the innocent suffer inscrutible failures because you think that many
mass distributions are wrong?  That is wrong.  I agree whole heartedly with
Gaby.

> But having multilib enabled by default on x86_64 is simply very highly
> desirable,

REMEMBER: we are talking about having a multilib enableable test in
the configure.  If it fails, then it is not enabled by default.  This is not
rocket science.

> If you don't have gmp or mfr installed,
> configure will let you know, loudly complains, and won't budge until
> you install the required tools

Exactly.

> >  It's better to abort early.
>
> it is, as the saying goes, drowning the baby because we want to
> keep the water.

:-D  It is punishing the innocent by failing the build with inscrutible
error messages.  Sounds like baby drowning to me...

Please add a multilib-able test to configure.  Thank you.

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

[Jakub Jelinek]

On Mon, Jul 08, 2013 at 08:11:03AM -0700, Bruce Korb wrote:
> > But having multilib enabled by default on x86_64 is simply very highly
> > desirable,
> 
> REMEMBER: we are talking about having a multilib enableable test in
> the configure.  If it fails, then it is not enabled by default.  This is not
> rocket science.

It isn't that trivial though, would you do this for native linux
configurations only (or how would you handle crosses?), what about
--with-sysroot configurations where the system compiler might e.g. not
support sysroots, what if the system compiler isn't gcc, or what if it is
gcc, but doesn't support multilibs, yet the newly built gcc would be capable
of supporting that?
So maybe for native configuration without --with-sysroot if system compiler
is gcc and a configure test can be compiled successfully when not using
any headers with a non-primary multilib option, but a test including some
well known glibc header like stdlib.h would fail with an error, error out
(silently disabling multilibs would look wrong to me, given that it
would be a very problematic heuristics only working sometimes).
But, the next question is how to find out what multilib options to pass,
if system compiler is gcc, it can check --print-multilib and derive that
info from it, but do you have a guarantee that the system gcc multilib
support matches the to be built compiler's multilib (e.g., you can have
system gcc built on ppc* to default to -m32 and have -m64 as non-default
multilib option and configure new gcc to do it the other way around, etc.).
Do you still think it is that trivial?

Far easier would be if not inhibit_libc to try to compile some trivial
program using say stdlib.h include in libgcc configure and error out there,
if it isn't for the primary multilib hint that either development support
for the non-primary multilib needs to be installed or --disable-multilib
used in configure.  That would have the disadvantage that the error would
show up only after at least first stage of gcc has been built, but would be
more reliable.

	Jakub

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

[Bruce Korb]

On Mon, Jul 8, 2013 at 8:24 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Far easier would be if not inhibit_libc to try to compile some trivial
> program using say stdlib.h include in libgcc configure and error out there,
> if it isn't for the primary multilib hint that either development support
> for the non-primary multilib needs to be installed or --disable-multilib
> used in configure.  That would have the disadvantage that the error would
> show up only after at least first stage of gcc has been built, but would be
> more reliable.

Any solution other than an explanation-less "fatal error:
gnu/stubs-32.h: No such file"
is fine.  There is no way to translate that message into
"Either --disable-multilib or else install glibc 32 bit development"
without coming up with the right Googling terms.  I managed to futz around
until I figured out the missing package.  It was a day later that I found out
it was all about multilib.  Putting people through such a gauntlet just because
you think a distro ought to have included glibc 32 bit development as part of
a development package is not appropriate.

So I see several choices.  Primarily, assume that more often than not, builds
are not cross builds, thus if multi-lib is not supported, likely the
build will fail
on the multilib part.  Therefore, disable it _by default_.  The user
has to override,
even if they are doing a cross build for a platform with multi-lib.
The user alters
the default if the host platform does not support it.  But anything at
all, as long
as the way forward is explicit and does not involve Google.

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

[Jonathan Wakely]

On Jul 8, 2013 4:39 PM, "Bruce Korb" wrote:
>
> Any solution other than an explanation-less "fatal error:
> gnu/stubs-32.h: No such file"
> is fine.  There is no way to translate that message into
> "Either --disable-multilib or else install glibc 32 bit development"
> without coming up with the right Googling terms.

I added http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h to improve things
slightly. I don't think http://gcc.gnu.org/install/prerequisites.html
mentions it so a patch to install.texi might be appropriate.

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

[Bruce Korb]

On 07/08/13 10:27, Jonathan Wakely wrote:
> I added http://gcc.gnu.org/wiki/FAQ#gnu_stubs-32.h to improve things
> slightly.

Ever so, but thank you.  Ultimately, searching for just "stubs-32.h"
will take you there and not require you to wade through too much chaff.
You're still Googling instead of reading "you need to disable multilib
or install a 32 bit development package", but it is ever so slightly
better now.

>I don't think http://gcc.gnu.org/install/prerequisites.html
> mentions it so a patch to install.texi might be appropriate.

That would be good.

Speaking of, the fixinclude directory has been moved from fixincl
to fixincludes.  _That_, surely, is pretty inconsequential....

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

[Florian Weimer]

On 07/08/2013 05:39 PM, Bruce Korb wrote:

> Any solution other than an explanation-less "fatal error:
> gnu/stubs-32.h: No such file"
> is fine.  There is no way to translate that message into
> "Either --disable-multilib or else install glibc 32 bit development"
> without coming up with the right Googling terms.

I think this is actually a glibc problem.  I wonder if it's possible to 
install a stubs-32.h file in a suitable location by default which 
contains an illuminating #error directive.  That file would be hidden by 
the real one if you install the actual 32 bit development environment.

-- 
Florian Weimer / Red Hat Product Security Team

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

[Gabriel Dos Reis]

On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 07/08/2013 05:39 PM, Bruce Korb wrote:
>
>> Any solution other than an explanation-less "fatal error:
>> gnu/stubs-32.h: No such file"
>> is fine.  There is no way to translate that message into
>> "Either --disable-multilib or else install glibc 32 bit development"
>> without coming up with the right Googling terms.
>
>
> I think this is actually a glibc problem.  I wonder if it's possible to
> install a stubs-32.h file in a suitable location by default which contains
> an illuminating #error directive.  That file would be hidden by the real one
> if you install the actual 32 bit development environment.
>
> --
> Florian Weimer / Red Hat Product Security Team

that wouldn't solve the failures on current systems.

-- Gaby

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

[Jonathan Wakely]

On 16 July 2013 13:46, Gabriel Dos Reis wrote:
> On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> I think this is actually a glibc problem.  I wonder if it's possible to
>> install a stubs-32.h file in a suitable location by default which contains
>> an illuminating #error directive.  That file would be hidden by the real one
>> if you install the actual 32 bit development environment.
>>
>> --
>> Florian Weimer / Red Hat Product Security Team
>
> that wouldn't solve the failures on current systems.

GCC sources could contain a gnu/stubs-32.h header with an #error and
ensure that the right directory to find it is searched when building
the target libraries, but only after all other directories.  It
wouldn't need to be installed with GCC because it's only needed while
configuring the target libs.

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

[Andrew Pinski]

On Tue, Jul 16, 2013 at 6:24 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 16 July 2013 13:46, Gabriel Dos Reis wrote:
>> On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> I think this is actually a glibc problem.  I wonder if it's possible to
>>> install a stubs-32.h file in a suitable location by default which contains
>>> an illuminating #error directive.  That file would be hidden by the real one
>>> if you install the actual 32 bit development environment.
>>>
>>> --
>>> Florian Weimer / Red Hat Product Security Team
>>
>> that wouldn't solve the failures on current systems.
>
> GCC sources could contain a gnu/stubs-32.h header with an #error and
> ensure that the right directory to find it is searched when building
> the target libraries, but only after all other directories.  It
> wouldn't need to be installed with GCC because it's only needed while
> configuring the target libs.

That only fixes x86_64 (and maybe powerpc), it does not fix the other
targets which use multi-lib (MIPS64 or soon AARCH64).

Thanks,
Andrew

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

[Bruce Korb]

On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>> GCC sources could contain a gnu/stubs-32.h header with an #error and
>> ensure that the right directory to find it is searched when building
>> the target libraries, but only after all other directories.  It
>> wouldn't need to be installed with GCC because it's only needed while
>> configuring the target libs.
>
> That only fixes x86_64 (and maybe powerpc), it does not fix the other
> targets which use multi-lib (MIPS64 or soon AARCH64).

Isn't a partial fix better than no fix?  And if the most common
architecture is, in fact,
x86-64, wouldn't a partial fix that fixed most users make it even more useful?
The point is is that it is fairly clear now that there are solutions
available that
will guide the misdirected without a great deal of difficulty.  That
_is_ a good thing.
Do not let the perfect get in the way of the good.

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

[Gabriel Dos Reis]

On Tue, Jul 16, 2013 at 9:35 AM, Bruce Korb <bruce.korb@gmail.com> wrote:
> On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>>> GCC sources could contain a gnu/stubs-32.h header with an #error and
>>> ensure that the right directory to find it is searched when building
>>> the target libraries, but only after all other directories.  It
>>> wouldn't need to be installed with GCC because it's only needed while
>>> configuring the target libs.
>>
>> That only fixes x86_64 (and maybe powerpc), it does not fix the other
>> targets which use multi-lib (MIPS64 or soon AARCH64).
>
> Isn't a partial fix better than no fix?  And if the most common
> architecture is, in fact,
> x86-64, wouldn't a partial fix that fixed most users make it even more useful?

Agreed.  It is surprising that we allowed ourselves to
break the most common target this way.

-- Gaby

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

[Jonathan Wakely]

On 16 July 2013 16:04, Gabriel Dos Reis wrote:
> Agreed.  It is surprising that we allowed ourselves to
> break the most common target this way.

It isn't broken, we just don't list one of the prerequisites in the
installation docs.

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

[Gabriel Dos Reis]

On Tue, Jul 16, 2013 at 10:11 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 16 July 2013 16:04, Gabriel Dos Reis wrote:
>> Agreed.  It is surprising that we allowed ourselves to
>> break the most common target this way.
>
> It isn't broken, we just don't list one of the prerequisites in the
> installation docs.

Ha, nice try; but no.

-- Gaby

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

[Bruce Korb]

On Tue, Jul 16, 2013 at 8:11 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 16 July 2013 16:04, Gabriel Dos Reis wrote:
>> Agreed.  It is surprising that we allowed ourselves to
>> break the most common target this way.
>
> It isn't broken, we just don't list one of the prerequisites in the
> installation docs.

In what way is this different from "broken"?
If it is inexplicably unusable, it _is_ broken.

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

[Alexandre Oliva]

(catching up on old email)

On Jul  8, 2013, 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 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.

Heh.  Back in 1999, I had a patch accepted that disabled the 64-bit
multilibs on mips*-*-* if we couldn't link a trivial program due to
missing 64-bit libraries on an IRIX5 box I used to have access to for
GCC testing back then.  It is a very different world indeed: now it's
the 32-bit libs that are frequently not available ;-)

trunk rev 26355, git commit a48ef8ee5c527137faa2aec5b9101ad63d41fbd6, if
anyone's interested.

FWIW, that patch was removed at a later point, for reasons I no longer
recall.  It surely didn't meet all the requirements mentioned in this
thread.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

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

[Andreas Schwab]

Alexandre Oliva <aoliva@redhat.com> writes:

> FWIW, that patch was removed at a later point, for reasons I no longer
> recall.

See <http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01693.html>.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Gabriel Dos Reis]

On Wed, Aug 14, 2013 at 11:23 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>
>> FWIW, that patch was removed at a later point, for reasons I no longer
>> recall.
>
> See <http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01693.html>.

So, we are over the 48-hour wait for complaints :-/

-- Gaby

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

[Russ Allbery]

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.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

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

[Jonathan Wakely]

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.

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

[Matthias Klose]

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

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

[Andrew Haley]

On 07/30/2013 01:52 PM, David Starner wrote:
> On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley <aph@redhat.com> wrote:
>> "We" is the GCC community.  "We" really want multilibs to be built so
>> they get tested as much as possible.  It's in the best interest of
>> all GCC users that this happens.
> 
> "We" really want Ada to be built so that it gets tested as much as
> possible. "We" really want ARM to be built so that it gets tested as
> much as possible. I don't see the distinction. Those who need
> multilibs support should be responsible for making sure that it works
> right. Presumably enough people do need it. Those that don't should
> have to shoulder the burden for those who do.

The burden of typing "--disable-multilib".

>> So don't write one.  Then you're likely to be proved right.
> 
> So what you're saying is that "we" don't care if people can easily
> build "our" compiler.

No.  I'm saying that you care enough to argue but not enough to write
a patch.  If you really wanted to change the status quo that's what
you'd have done by now.

Andrew.

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

[FX]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

> If --enable-multilib or --disable-multilib are passed then things
> are performed as today, more or less.  If these flags are not
> explicitly given then gcc has to do something different

This sounds reasonable. We could have a specific check, with the following cumulative conditions (to make it as unobtrusive as possible for current users). If:

  1. we build a native compiler
  2. on x86_64-linux (and possible other x86_64 targets whose maintainers want to opt in)
  3. and neither --enable-multilib nor --disable-multilib were passed

then:

  a. we check that the native compiler can handle 32-bit, by compiling a test executable with the "-m32" option
  b. if we fail, we error out of the configure process, indicating that this can be overriden with --{enable,disable}-multilib

I suspect this might catch (at configure time) the large majority of users who currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while being invisible to a large majority of the power users.

Question: what are the pitfalls of the test proposed above? are there typical use cases that I have not thought of, and that would trigger this check?

FX


PS: I attach a tentative patch implementing such as check in configure.ac.


[-- Attachment #2: 64bit_configure_patch.txt --]
[-- Type: text/plain, Size: 1270 bytes --]

Index: configure.ac
===================================================================
--- configure.ac	(revision 201292)
+++ configure.ac	(working copy)
@@ -2861,6 +2861,26 @@ case "${target}" in
     ;;
 esac
 
+# Special user-friendly check for native x86_64-linux build, if
+# multilib is not explicitly enabled.
+case "$target:$have_compiler:$host:$target:$enable_multilib" in
+  x86_64-*linux*:yes:$build:$build:)
+    # Make sure we have a developement environment that handles 32-bit
+    dev64=no
+    echo "int main () { return 0; }" > conftest.c
+    ${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c
+    if test $? = 0 ; then
+      if test -s conftest || test -s conftest.exe ; then
+	dev64=yes
+      fi
+    fi 
+    rm -f conftest*
+    if test x${dev64} != xyes ; then
+      AC_MSG_ERROR([I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
+    fi
+    ;;
+esac
+
 # Default to --enable-multilib.
 if test x${enable_multilib} = x ; then
   target_configargs="--enable-multilib ${target_configargs}"

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

[David Starner]

On Mon, Jul 29, 2013 at 9:58 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 9:50 PM, David Starner <prosfilaes@gmail.com> wrote:
>> We've all seen cases where a quick patch is rejected in favor of a
>> hypothetical patch, and years down the road, the program still has the
>> problem. The people who blocked the quick patch, naturally, never
>> bothered trying to write the patch they wanted.
>
> The problem here is a quick patch makes the situation worse rather
> than better.  That is the reason why the quick patch is rejected.

If it were replaced with a better one, that wouldn't be a problem.

> The defaults are there for the
> majority of users

That remains to be seen. As I said, a substantial majority of Debian
users on AMD64 who can compile C programs can't compile for 32 bits.

> and majority of users of compiling a compiler knows
> the risks of not having the current libraries installed.

The "current" libraries? Currency has nothing to do with it. The libc
development files for a 32-bit system, which are normally not needed
for compiling on a pure 64-bit system. In any case, a couple normal
developers on this list have said that has bit them.

> That is because it is a hard to do and will force extra time in
> compiling and might cause incorrect handling of cross builds.
> Remember the host compiler does not have to compile for the multi-lib;
> only the newly compiled compiler will be able to.

Which goes straight to my first point. There is a build-time bug in
GCC that will bite many Linux AMD64 users who might be interesting in
trying to build a new version of GCC. It apparently will be there for
many years. Certainly this reduces any inclination I might have had of
actually trying to figure out GCC's build system and find a patch, as
Andrew Haley suggests.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[David Starner]

On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley <aph@redhat.com> wrote:
> "We" is the GCC community.  "We" really want multilibs to be built so
> they get tested as much as possible.  It's in the best interest of
> all GCC users that this happens.

"We" really want Ada to be built so that it gets tested as much as
possible. "We" really want ARM to be built so that it gets tested as
much as possible. I don't see the distinction. Those who need
multilibs support should be responsible for making sure that it works
right. Presumably enough people do need it. Those that don't should
have to shoulder the burden for those who do.

> So don't write one.  Then you're likely to be proved right.

So what you're saying is that "we" don't care if people can easily
build "our" compiler.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Michael Veksler]

On 07/30/2013 07:50 AM, David Starner wrote:
> Sorry about the blank message; I accidentally hit the wrong button.
>
> On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <aph@redhat.com> wrote:
>> 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."
> We've all seen cases where a quick patch is rejected in favor of a
> hypothetical patch, and years down the road, the program still has the
> problem. The people who blocked the quick patch, naturally, never
> bothered trying to write the patch they wanted.
>
>> 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.
This is an interesting conflict of requirements. I see the point of both
sides, being a developer on one side and being a user on the other.
I really appreciate the fact that I got a clear message telling me to
install mpc. I would have hated needing to google for a cryptic error
message.

How about a middle-ground, not aiming at cross compilation?
If --enable-multilib or --disable-multilib are passed then things
are performed as today, more or less.  If these flags are not
explicitly given then gcc has to do something different:

If the system compiler is GCC then 'configure' tries if the system
GCC can build i686/x86-64/x32/etc. If the system gcc creates
workable executables then all is fine and 'configure' proceeds
to a multilib build.

Otherwise an error will be emitted saying something like:
"
   I can't figure out if your system has [???] development libraries.
   If you have [???] then rerun configure with
    --enable-multilib
If you don't have [???] then you should rerun configure with
    --disable-multilib

   You should note that if you pass --enable-multilib despite having
   no [???] development  libraries,  then you would likely get the
   following error at the last stages of bulid:
     gnu/stubs-[???].h: No such file
"

This should be relatively simple to implement, and will catch most
cases. I guess that a native English speaker can phrase something
more readable and welcoming.

Michael

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

[Andrew Haley]

On 07/30/2013 05:50 AM, David Starner wrote:
> Sorry about the blank message; I accidentally hit the wrong button.
> 
> On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <aph@redhat.com> wrote:
>> 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."
> 
> We've all seen cases where a quick patch is rejected in favor of a
> hypothetical patch, and years down the road, the program still has the
> problem. The people who blocked the quick patch, naturally, never
> bothered trying to write the patch they wanted.

This is true.  It is a real problem.

However, it's up to the proposer to propose something that works
for everyone.  No-one would object to a decent diagnostic.

>> 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.
> 
> Who is we here? And why do you really want multilibs built?

"We" is the GCC community.  "We" really want multilibs to be built so
they get tested as much as possible.  It's in the best interest of
all GCC users that this happens.

>>> 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!
> 
> Then what are we going to do about it? As per my first comment, nobody
> has offered to produce a patch in the form you would be happy with, so
> I'm not going to hold my breath that it's going to appear.

So don't write one.  Then you're likely to be proved right.

Andrew.

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

[Andrew Pinski]

On Mon, Jul 29, 2013 at 9:50 PM, David Starner <prosfilaes@gmail.com> wrote:
> Sorry about the blank message; I accidentally hit the wrong button.
>
> On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <aph@redhat.com> wrote:
>> 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."
>
> We've all seen cases where a quick patch is rejected in favor of a
> hypothetical patch, and years down the road, the program still has the
> problem. The people who blocked the quick patch, naturally, never
> bothered trying to write the patch they wanted.

The problem here is a quick patch makes the situation worse rather
than better.  That is the reason why the quick patch is rejected.

>
>> 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.
>
> Who is we here? And why do you really want multilibs built?

The simple answer is testing, you should be build the multi-libs which
are there for your target that means 32bit for x86_64.  If you don't
want them, explicitly disable them.  The defaults are there for the
majority of users and majority of users of compiling a compiler knows
the risks of not having the current libraries installed.

>>> 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!
>
> Then what are we going to do about it? As per my first comment, nobody
> has offered to produce a patch in the form you would be happy with, so
> I'm not going to hold my breath that it's going to appear.

That is because it is a hard to do and will force extra time in
compiling and might cause incorrect handling of cross builds.
Remember the host compiler does not have to compile for the multi-lib;
only the newly compiled compiler will be able to.

Thanks,
Andrew Pinski


>
> --
> Kie ekzistas vivo, ekzistas espero.

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

[David Starner]

Sorry about the blank message; I accidentally hit the wrong button.

On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <aph@redhat.com> wrote:
> 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."

We've all seen cases where a quick patch is rejected in favor of a
hypothetical patch, and years down the road, the program still has the
problem. The people who blocked the quick patch, naturally, never
bothered trying to write the patch they wanted.

> 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.

Who is we here? And why do you really want multilibs built?

>> 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!

Then what are we going to do about it? As per my first comment, nobody
has offered to produce a patch in the form you would be happy with, so
I'm not going to hold my breath that it's going to appear.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[David Starner]

On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley <aph@redhat.com> wrote:
> 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.



-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

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.

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

[Bruce Korb]

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.

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

[Andrew Haley]

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}

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

[FX]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

> 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


[-- Attachment #2: multilib_patch.txt --]
[-- Type: text/plain, Size: 1280 bytes --]

Index: install.texi
===================================================================
--- install.texi	(revision 201292)
+++ install.texi	(working copy)
@@ -255,6 +255,26 @@ may need to use @option{--disable-stage1
 bootstrapping the compiler with such earlier compilers is strongly
 discouraged.
 
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+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
+
 @item GNAT
 
 In order to build the Ada compiler (GNAT) you must already have GNAT

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

[FX]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

> The fact it's not listed as a prerequesite has already been pointed
> out as a problem with the docs.

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.)

FX



[-- Attachment #2: multilib_patch.txt --]
[-- Type: text/plain, Size: 1280 bytes --]

Index: install.texi
===================================================================
--- install.texi	(revision 201292)
+++ install.texi	(working copy)
@@ -255,6 +255,26 @@ may need to use @option{--disable-stage1
 bootstrapping the compiler with such earlier compilers is strongly
 discouraged.
 
+@item C standard library and headers
+
+In order to build GCC, the C standard library and headers must be present
+for all target variants for which target libraries will be built (and not
+only the variant of the host C++ compiler).
+
+This affects the popular @samp{x86_64-unknown-linux-gnu} platform (among
+other multilib targets), for which 64-bit (@samp{x86_64}) and 32-bit
+(@samp{i386}) libc headers are usually packaged separately. If you do a
+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
+
 @item GNAT
 
 In order to build the Ada compiler (GNAT) you must already have GNAT

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

[Gabriel Dos Reis]

On Sat, Jul 27, 2013 at 6:10 PM, David Starner <prosfilaes@gmail.com> wrote:
>> If the
>> latter, did you try spelling it correctly, --disable-multilib
>> (singular)?
>
> I'm sorry, I didn't realize I was misspelling it.

Do not feel alone on this one.

-- Gaby

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

[David Starner]

On Sat, Jul 27, 2013 at 12:23 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> It's not "some random package" it's the C library, and it is needed to
> compile 32-bit C programs.

It's not libc6. It's not even libc6-dev. It's libc6-dev-i386. Debian
Popularity Contest says that 84315 out of 147631 are AMD64; 99980
systems out of 147631 have libc6-dev installed; and yet only 7712
(presumably all AMD64) have libc6-dev-i386 installed (+740 with the
obsolete ia32-libs-dev). Any way I cut it, most people who have the C
library development package on AMD64 installed don't have the
libc6-dev-i386 package installed.

> If the
> latter, did you try spelling it correctly, --disable-multilib
> (singular)?

I'm sorry, I didn't realize I was misspelling it. Again, failing with
some random bug in the middle of compilation is not generally a sign
of that type of error.

> In any case, the point stands: someone needs to do the work, insisting
> on it being done doesn't do it.

That's not the point. I can send you a patch pretty quickly that
changes the default on AMD64 from --enable-multilib to
--disable-multilib. I've been told it's impossible to fix it any other
way, and saying "It is clearly a computable problem" is quite a
distance from saying "oh, we can fix this". If you can fix this
without changing the default, that's great, but nobody has even said
that's a solvable problem, except in the theoretical sense. I don't
care how it's fixed, but if you want me to do it, I'm going to make
the simple configuration fix instead of the possibly intractable
library detect patch.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Gabriel Dos Reis]

On Sat, Jul 27, 2013 at 2:23 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 27 July 2013 14:56, David Starner wrote:
>> On Fri, Jul 26, 2013 at 2:01 AM, Andrew Haley <aph@redhat.com> wrote:
>>> GCC can detect at configure time that it will fail.  It is clearly
>>> a computable problem.  It's a matter of someone doing it rather than
>>> insisting that the world should change to suit them.
>>
>> GCC 4.8.1 will fail to compile on x86_64-unknown-linux-gnu that has
>> all the programs that Prerequisites in the Installation instructions
>> lists. That I install some random package not needed to build C
>> programs is not listed as a prerequisite in the documentation.
>
> It's not "some random package" it's the C library, and it is needed to
> compile 32-bit C programs.
>
> The fact it's not listed as a prerequesite has already been pointed
> out as a problem with the docs.

Although that is an improvement, it is still far away from solving
the problem.  I read all the arguments, it still looks wrong to me.

>
>> I don't
>> regard objecting to that is a matter of the world should change to
>> suit me, rather as GCC not compiling on a system that it lists as a
>> primary platform and is one of the most common targets for it. (It,
>> BTW, does not suffice to add --disable-multilibs.)
>
> What do you mean it does not suffice? Do you mean it's not a good
> enough solution, or it doesn't actually solve the problem?  If the
> latter, did you try spelling it correctly, --disable-multilib
> (singular)?

See, this is also another trap (yep, it happened to me long ago on
multiple occasions).

> In any case, the point stands: someone needs to do the work, insisting
> on it being done doesn't do it.

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

[Jonathan Wakely]

On 27 July 2013 14:56, David Starner wrote:
> On Fri, Jul 26, 2013 at 2:01 AM, Andrew Haley <aph@redhat.com> wrote:
>> GCC can detect at configure time that it will fail.  It is clearly
>> a computable problem.  It's a matter of someone doing it rather than
>> insisting that the world should change to suit them.
>
> GCC 4.8.1 will fail to compile on x86_64-unknown-linux-gnu that has
> all the programs that Prerequisites in the Installation instructions
> lists. That I install some random package not needed to build C
> programs is not listed as a prerequisite in the documentation.

It's not "some random package" it's the C library, and it is needed to
compile 32-bit C programs.

The fact it's not listed as a prerequesite has already been pointed
out as a problem with the docs.

> I don't
> regard objecting to that is a matter of the world should change to
> suit me, rather as GCC not compiling on a system that it lists as a
> primary platform and is one of the most common targets for it. (It,
> BTW, does not suffice to add --disable-multilibs.)

What do you mean it does not suffice? Do you mean it's not a good
enough solution, or it doesn't actually solve the problem?  If the
latter, did you try spelling it correctly, --disable-multilib
(singular)?

In any case, the point stands: someone needs to do the work, insisting
on it being done doesn't do it.

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

[David Starner]

On Fri, Jul 26, 2013 at 2:01 AM, Andrew Haley <aph@redhat.com> wrote:
> GCC can detect at configure time that it will fail.  It is clearly
> a computable problem.  It's a matter of someone doing it rather than
> insisting that the world should change to suit them.

GCC 4.8.1 will fail to compile on x86_64-unknown-linux-gnu that has
all the programs that Prerequisites in the Installation instructions
lists. That I install some random package not needed to build C
programs is not listed as a prerequisite in the documentation. I don't
regard objecting to that is a matter of the world should change to
suit me, rather as GCC not compiling on a system that it lists as a
primary platform and is one of the most common targets for it. (It,
BTW, does not suffice to add --disable-multilibs.)

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

On 07/26/2013 01:00 AM, David Starner wrote:
> On Thu, Jul 25, 2013 at 1:17 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 07/24/2013 11:51 PM, David Starner wrote:
>>> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> Not at all: we're just disagreeing about what a real system with
>>>> a real workload looks like.
>>>
>>> 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.
>>
>> No we aren't.  I want that error message fixed too.  A configure-
>> time warning would be good.
> 
> The obscurity of the error message is only part of the problem; the
> fact that it errors out halfway through a multi-hour build is also an
> issue. The question is if it can't detect a compile time that this
> will fail, should GCC disable multilibs?

GCC can detect at configure time that it will fail.  It is clearly
a computable problem.  It's a matter of someone doing it rather than
insisting that the world should change to suit them.

Andrew.

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

[David Starner]

On Thu, Jul 25, 2013 at 1:17 AM, Andrew Haley <aph@redhat.com> wrote:
> On 07/24/2013 11:51 PM, David Starner wrote:
>> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley <aph@redhat.com> wrote:
>>> Not at all: we're just disagreeing about what a real system with
>>> a real workload looks like.
>>
>> 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.
>
> No we aren't.  I want that error message fixed too.  A configure-
> time warning would be good.

The obscurity of the error message is only part of the problem; the
fact that it errors out halfway through a multi-hour build is also an
issue. The question is if it can't detect a compile time that this
will fail, should GCC disable multilibs?

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

On 07/24/2013 11:51 PM, David Starner wrote:
> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley <aph@redhat.com> wrote:
>> Not at all: we're just disagreeing about what a real system with
>> a real workload looks like.
> 
> 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.

No we aren't.  I want that error message fixed too.  A configure-
time warning would be good.

> Real systems need features that aren't enabled by default sometimes.

I *totally* agree.

>> It's a stupid thing to say anyway, because who is to say their
>> system is more real than mine or yours?
> 
> By that logic, you've already said that any system needing GNAT is
> less real then others, because it's not enabled by default.

Absolutely not: you're the one making claims about "real systems and
real workloads".  I made no such claims.

Andrew.

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

[David Starner]

On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley <aph@redhat.com> wrote:
> Not at all: we're just disagreeing about what a real system with
> a real workload looks like.

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.

> It's a stupid thing to say anyway, because
> who is to say their system is more real than mine or yours?

By that logic, you've already said that any system needing GNAT is
less real then others, because it's not enabled by default.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

On 07/24/2013 04:38 PM, Gabriel Dos Reis wrote:
> On Wed, Jul 24, 2013 at 8:44 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote:
>>>> There is no resistance whatsoever to making it work with real systems
>>>> and real workloads.
>>>
>>> It does not sound or look like that way.
>>>
>>>>  The problem is that you don't know that people
>>>> running on 64-bit hardware often choose to compile -32 and run -32
>>>> locally.
>>>
>>> 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.
> 
> I suspect this might just provide evidence for a claim previously denied.

Not at all: we're just disagreeing about what a real system with
a real workload looks like.  It's a stupid thing to say anyway, because
who is to say their system is more real than mine or yours?

Andrew.

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

[Gabriel Dos Reis]

On Wed, Jul 24, 2013 at 8:44 AM, Andrew Haley <aph@redhat.com> wrote:
> On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote:
>>> There is no resistance whatsoever to making it work with real systems
>>> and real workloads.
>>
>> It does not sound or look like that way.
>>
>>>  The problem is that you don't know that people
>>> running on 64-bit hardware often choose to compile -32 and run -32
>>> locally.
>>
>> 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.

I suspect this might just provide evidence for a claim previously denied.

-- Gaby

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

[Andrew Haley]

On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote:
>> There is no resistance whatsoever to making it work with real systems
>> and real workloads.
> 
> It does not sound or look like that way.
> 
>>  The problem is that you don't know that people
>> running on 64-bit hardware often choose to compile -32 and run -32
>> locally.
> 
> 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.

Andrew.

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

[Andrew Haley]

On 07/24/2013 01:26 PM, David Starner wrote:
> On Wed, Jul 24, 2013 at 4:14 AM, Andrew Haley <aph@redhat.com> wrote:
>> I would just install GCC's build dependencies and build with the
>> defaults.
> 
> I'm glad you have infinite hard-drive space. I rather wish fewer
> developers did, as well as those infinitely fast computers they seem
> to have; perhaps they would have more empathy with my day-to-day
> computing needs.
> 
>> There is no resistance whatsoever to making it work with real systems
>> and real workloads.
> 
> Yes, there is. Both in this thread, and on bugzilla, people with real
> systems, in my case a well-stocked development system, have said they
> started compiling gcc and after hours the compile has failed without
> even an explanation, and people have shrugged, and said what do you
> want us to do about it?

There should be a better diagnostic.

Andrew.

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

[Gabriel Dos Reis]

> There is no resistance whatsoever to making it work with real systems
> and real workloads.

It does not sound or look like that way.

>  The problem is that you don't know that people
> running on 64-bit hardware often choose to compile -32 and run -32
> locally.

But we know people are running into this issue and reporting it.

-- Gaby

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

[David Starner]

On Wed, Jul 24, 2013 at 4:14 AM, Andrew Haley <aph@redhat.com> wrote:
> I would just install GCC's build dependencies and build with the
> defaults.

I'm glad you have infinite hard-drive space. I rather wish fewer
developers did, as well as those infinitely fast computers they seem
to have; perhaps they would have more empathy with my day-to-day
computing needs.

> There is no resistance whatsoever to making it work with real systems
> and real workloads.

Yes, there is. Both in this thread, and on bugzilla, people with real
systems, in my case a well-stocked development system, have said they
started compiling gcc and after hours the compile has failed without
even an explanation, and people have shrugged, and said what do you
want us to do about it? If a feature causes failure on real systems
like that, then disabling it by default, even if it's used by a
significant minority of users, should be considered. Yes, it would be
better to leave multilibs on and give people building without 32-bit
libraries a proper error message up front, but leaving it as is is not
making it work with real systems; it's causing real people to pull
their hair out or give up on trying to build GCC.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

On 07/24/2013 11:32 AM, David Starner wrote:
> On Wed, Jul 24, 2013 at 1:17 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 07/24/2013 01:48 AM, David Starner wrote:
>>> I'd like to mention that I too was bit by this one on Debian. I don't
>>> have a 32-bit development environment installed; why would I? I'm
>>> building primarily for myself, and if I did have to target a 32-bit
>>> environment, I'd likely have to mess with more stuff then just the
>>> compiler.
>>
>> No, you probably wouldn't.  Just use -m32 and you'd be fine.
> 
> That's assuming that the hypothetical 32-bit x86 system I was
> targeting was running GNU libc6 2.17 (as well as whatever libraries
> I need, with version numbers apropos of Debian Unstable.)
> Conceivable, but not something I'd bet on. I've got 3 ARM (Android)
> computers around, and 3 AMD-64 computers, and I can't imagine why
> I'd need an x86 computer. There is one x86 program I run (zsnes),
> but if Debian stopped carrying it, it probably wouldn't be worth the
> time to compile it myself.

No, I'm assuming you want to build and run an x86 program on your own
system.  -32 is not in any sense a cross-compiler.

>>> If you can't find a way to detect this error, I can't
>>> imagine many people would have a problem with turning off multilibs on
>>> x86-64; it's something of a minority setup.
>>
>> I don't think it is, really.
> 
> Really?

Really.

> Because my impression is that on Unix, the primary use of the
> C compiler has always been to compile programs for the system the
> compiler is running on.

So, use the system's C compiler.

> And x86-32 is a slow, largely obsolete chip; it's certainly useful
> to emulate, but I suspect any developer who needs to build for it
> knows that up-front and is prepared to deal for it in the same way
> that someone who needs an ARM or MIPS compiler is.
> 
>> Anyone building GCC for themself has a reason for doing so.
> 
> At the current time, Debian's version of GNAT is built from older
> sources then the rest of GCC; if I want a 4.8 version of GNAT, I have
> to build it myself.

So you have a specialized use.  Fair enough; you can disable multilib.
I would just install GCC's build dependencies and build with the
defaults.

>> Right, so it should be built the right way.
> 
> The right way?

The default way, then.

> If I don't want to build support for obsolete systems I don't use,
> I'm building it the wrong way? If I were building ia64-linux-gnu, I
> wouldn't have to enable support for x86-linux-gnu, but because I'm
> building amd64-linux-gnu, if I don't, I'm building it the wrong way?
> 
> I don't see this resistance to making it work with real systems and
> real workloads. This feature is not useful to many of us, and fails
> the GCC build in the middle. That's not really acceptable.

There is no resistance whatsoever to making it work with real systems
and real workloads.  The problem is that you don't know that people
running on 64-bit hardware often choose to compile -32 and run -32
locally.

Andrew.

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

[David Starner]

On Wed, Jul 24, 2013 at 1:17 AM, Andrew Haley <aph@redhat.com> wrote:
> On 07/24/2013 01:48 AM, David Starner wrote:
>> I'd like to mention that I too was bit by this one on Debian. I don't
>> have a 32-bit development environment installed; why would I? I'm
>> building primarily for myself, and if I did have to target a 32-bit
>> environment, I'd likely have to mess with more stuff then just the
>> compiler.
>
> No, you probably wouldn't.  Just use -m32 and you'd be fine.

That's assuming that the hypothetical 32-bit x86 system I was
targeting was running GNU libc6 2.17 (as well as whatever libraries I
need, with version numbers apropos of Debian Unstable.) Conceivable,
but not something I'd bet on. I've got 3 ARM (Android) computers
around, and 3 AMD-64 computers, and I can't imagine why I'd need an
x86 computer. There is one x86 program I run (zsnes), but if Debian
stopped carrying it, it probably wouldn't be worth the time to compile
it myself.

>> If you can't find a way to detect this error, I can't
>> imagine many people would have a problem with turning off multilibs on
>> x86-64; it's something of a minority setup.
>
> I don't think it is, really.

Really? Because my impression is that on Unix, the primary use of the
C compiler has always been to compile programs for the system the
compiler is running on. And x86-32 is a slow, largely obsolete chip;
it's certainly useful to emulate, but I suspect any developer who
needs to build for it knows that up-front and is prepared to deal for
it in the same way that someone who needs an ARM or MIPS compiler is.

> Anyone building GCC for themself has a reason for doing so.

At the current time, Debian's version of GNAT is built from older
sources then the rest of GCC; if I want a 4.8 version of GNAT, I have
to build it myself.

> Right, so it should be built the right way.

The right way? If I don't want to build support for obsolete systems I
don't use, I'm building it the wrong way? If I were building
ia64-linux-gnu, I wouldn't have to enable support for x86-linux-gnu,
but because I'm building amd64-linux-gnu, if I don't, I'm building it
the wrong way?

I don't see this resistance to making it work with real systems and
real workloads. This feature is not useful to many of us, and fails
the GCC build in the middle. That's not really acceptable.

-- 
Kie ekzistas vivo, ekzistas espero.

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

[Andrew Haley]

On 07/24/2013 10:04 AM, Florian Weimer wrote:
> On 07/24/2013 10:39 AM, Andrew Haley wrote:
> 
>> Well, of course.  It's a prerequisite for building GCC.  I presume that
>> Debian has the same abilities as Fedora, where if you want to build GCC
>> you just type
>>
>>    yum-builddep gcc
>>
>> and Fedora installs all the build reqs for GCC.
> 
> Yes, "apt-get build-dep gcc" should work, but will install quite a bit 
> of other stuff that's not needed for building the more popular front ends.

That is not of any significant consequence.

>>> I don't think that's easy to change because of the way dpkg handles file
>>> conflicts (even if the files are identical) and how true multi-arch
>>> support is implemented in Debian.
>>
>> But hold on: if I just wanted to compile C programs I'd use the system's
>> C compiler.  Anyone building GCC for themself has a reason for doing so.
> 
> I suspect a fairly common exercise is to check if the trunk still has 
> the bug you're about to report.

Right, so it should be built the right way.

Andrew.

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

[Florian Weimer]

On 07/24/2013 10:39 AM, Andrew Haley wrote:

> Well, of course.  It's a prerequisite for building GCC.  I presume that
> Debian has the same abilities as Fedora, where if you want to build GCC
> you just type
>
>    yum-builddep gcc
>
> and Fedora installs all the build reqs for GCC.

Yes, "apt-get build-dep gcc" should work, but will install quite a bit 
of other stuff that's not needed for building the more popular front ends.

>> I don't think that's easy to change because of the way dpkg handles file
>> conflicts (even if the files are identical) and how true multi-arch
>> support is implemented in Debian.
>
> But hold on: if I just wanted to compile C programs I'd use the system's
> C compiler.  Anyone building GCC for themself has a reason for doing so.

I suspect a fairly common exercise is to check if the trunk still has 
the bug you're about to report.

-- 
Florian Weimer / Red Hat Product Security Team

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

[Andrew Haley]

On 07/24/2013 09:35 AM, Florian Weimer wrote:
> On 07/24/2013 10:17 AM, Andrew Haley wrote:
>> On 07/24/2013 01:48 AM, David Starner wrote:
>>> I'd like to mention that I too was bit by this one on Debian. I don't
>>> have a 32-bit development environment installed; why would I? I'm
>>> building primarily for myself, and if I did have to target a 32-bit
>>> environment, I'd likely have to mess with more stuff then just the
>>> compiler.
>>
>> No, you probably wouldn't.  Just use -m32 and you'd be fine.
> 
> No, that doesn't work.  The glibc development environment on 
> Debian/amd64 does not contain the 32-bit header files, and that's where 
> the error message comes from.

Well, of course.  It's a prerequisite for building GCC.  I presume that
Debian has the same abilities as Fedora, where if you want to build GCC
you just type

  yum-builddep gcc

and Fedora installs all the build reqs for GCC.

> I don't think that's easy to change because of the way dpkg handles file 
> conflicts (even if the files are identical) and how true multi-arch 
> support is implemented in Debian.

But hold on: if I just wanted to compile C programs I'd use the system's
C compiler.  Anyone building GCC for themself has a reason for doing so.

Andrew.

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

[Florian Weimer]

On 07/24/2013 10:17 AM, Andrew Haley wrote:
> On 07/24/2013 01:48 AM, David Starner wrote:
>> I'd like to mention that I too was bit by this one on Debian. I don't
>> have a 32-bit development environment installed; why would I? I'm
>> building primarily for myself, and if I did have to target a 32-bit
>> environment, I'd likely have to mess with more stuff then just the
>> compiler.
>
> No, you probably wouldn't.  Just use -m32 and you'd be fine.

No, that doesn't work.  The glibc development environment on 
Debian/amd64 does not contain the 32-bit header files, and that's where 
the error message comes from.

I don't think that's easy to change because of the way dpkg handles file 
conflicts (even if the files are identical) and how true multi-arch 
support is implemented in Debian.

-- 
Florian Weimer / Red Hat Product Security Team

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

[Andrew Haley]

On 07/24/2013 01:48 AM, David Starner wrote:
> I'd like to mention that I too was bit by this one on Debian. I don't
> have a 32-bit development environment installed; why would I? I'm
> building primarily for myself, and if I did have to target a 32-bit
> environment, I'd likely have to mess with more stuff then just the
> compiler.

No, you probably wouldn't.  Just use -m32 and you'd be fine.

> If you can't find a way to detect this error, I can't
> imagine many people would have a problem with turning off multilibs on
> x86-64; it's something of a minority setup.

I don't think it is, really.

Andrew.

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

[David Starner]

I'd like to mention that I too was bit by this one on Debian. I don't
have a 32-bit development environment installed; why would I? I'm
building primarily for myself, and if I did have to target a 32-bit
environment, I'd likely have to mess with more stuff then just the
compiler. If you can't find a way to detect this error, I can't
imagine many people would have a problem with turning off multilibs on
x86-64; it's something of a minority setup.

-- 
Kie ekzistas vivo, ekzistas espero.