From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8157 invoked by alias); 17 May 2005 14:12:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8106 invoked from network); 17 May 2005 14:12:28 -0000 Received: from unknown (HELO mail.oarcorp.com) (216.107.91.226) by sourceware.org with SMTP; 17 May 2005 14:12:28 -0000 Received: (qmail 7195 invoked from network); 17 May 2005 14:12:26 -0000 Received: from unknown (HELO OARcorp.com) (192.168.1.2) by mail.oarcorp.com with SMTP; 17 May 2005 14:12:26 -0000 Message-ID: <4289FBA7.6080301@OARcorp.com> Date: Tue, 17 May 2005 16:02:00 -0000 From: "Joel Sherrill " Reply-To: joel.sherrill@OARcorp.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Steven Bosscher CC: Ralf Corsepius , GCC List Subject: Re: GCC 4.1: Buildable on GHz machines only? References: <17009.2368.986169.753001@cuddles.cambridge.redhat.com> <200505170010.48984.stevenb@suse.de> <1116291223.8237.766.camel@mccallum.corsepiu.local> <200505170259.37615.stevenb@suse.de> In-Reply-To: <200505170259.37615.stevenb@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00894.txt.bz2 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