GCC 4.1: Buildable on GHz machines only?

Tue May 17 16:02:00 GMT 2005

This is really getting pretty far from the original topic but
I am diving in anyway.

Steven Bosscher wrote:
> On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
> 
>>On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
>>
>>>On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
>>>
>>>>On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
>>>>
>>>>>Until package maintainers take cross-compilation *seriously*, I have
>>>>>no choice but to do native compilation of a large hunk of the
>>>>>packages on eval boards that can literally takes *DAYS* to build.
>>>>
>>>>The most amazing fact to me is: Not even GCC seems to take cross-
>>>>compilation seriously :(
>>>
>>>BS.  Even the large disto builders do cross compilations a lot.
>>
>>So I suppose you have these general crossbuilding PRs fixed in your
>>sources:
>>
>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
> 
> 
> No, I just don't build gfortran as a cross.  There are many reasons
> why this is a bad idea anyway.

Why is something broken in the gfortran build infrastructure?

Assuming not, then it should only be a matter of needed functionality
in the target C library and native FP types.  I know gfortran
currently makes assumptions about the FP capabilities of a CPU
and some don't meet that.  But there is no reason one should not
be able use an x86 GNU/Linux system to cross build gfortran for
a powerpc or arm GNU/Linux system.

> Oh, and how helpful of you to post that patch to gcc-patches@ too...
> NOT!

Personal gripe.. I still don't know why posting a patch with a PR isn't 
sufficient. GCC has two independent systems.  Why can't Bugzilla just 
forward attachments marked as patches?

Is there anywhere in the GCC problem reporting instructions that says
attaching a patch to a PR is insufficient?  I know you don't get that
impression from the Bugzilla page you use to add it.

>>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
> 
> 
> I don't build Ada cross either, but AdaCore does, so you could ask
> them to help you with this problem.

I don't really think they are the answer here.  GNAT has always been
implemented in Ada and has never been buildable without a native Ada 
compiler.  That's just the way it is.

The issue is what VERSION of GNAT is required to compile version X
of GNAT.  I don't try to track minimum versions required but in this
case, I think it moved up quite a bit.  From install.texi in gcc-4.0.0:

=================================================================
In order to build GNAT, the Ada compiler, you need a working GNAT
compiler (GNAT version 3.14 or later, or GCC version 3.1 or later),
including GNAT tools such as @command{gnatmake} and @command{gnatlink},
since the Ada front end is written in Ada (with some
GNAT-specific extensions), and GNU make.
==================================================================

So this could be viewed as only a documentation issue except that
one has to know where to get a binary for GNAT to start the build
process with.

Personally, I have always avoided this by building a native GNAT
first and using that to build the cross-GNAT.  It avoids this
issue entirely.

AdaCore has always helped avoid the problem by providing pre-built
binaries for a few platforms.  You can use these to kick-start
the process.

>>Another one I haven't filed yet, is GCC-4.x not correctly propagating
>>CFLAGS/CFLAGS_FOR_{BUILD|HOST|TARGET} to newlib in one-tree builds (I am
>>still investigating).
> 
> 
> I don't build with newlib either.

I think that's the point -- no one builds all configurations so
everyone has to be very careful to use the right build magic
to keep them all working.

>>All these to me are strong indications that GCC-4.x has been poorly
>>tested in cross compilation.
> 
> 
> No, just in the configurations you are using.

Possibly.  RTEMS may be the only non-GNU/Linux embedded cross target 
which tries to stay near the GCC head and is able to reasonably fully 
support languages other than C and C++.

The *-elf targets don't have the filesystem and threading support
required to fully support some of the other language run-times.

> And since you're not posting the patches you attach to the bugzilla
> PRs you open, you're not exactly helping to make things better either.
> 
> Gr.
> Steven

--joel