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
