From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11465 invoked by alias); 30 Nov 2007 04:16:38 -0000 Received: (qmail 11444 invoked by uid 22791); 30 Nov 2007 04:16:36 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Nov 2007 04:16:30 +0000 Received: (qmail 30535 invoked from network); 30 Nov 2007 04:16:27 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Nov 2007 04:16:27 -0000 Message-ID: <474F8E96.8000605@codesourcery.com> Date: Fri, 30 Nov 2007 11:41:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Rask Ingemann Lambertsen CC: Bernd Schmidt , Jie Zhang , gcc@gcc.gnu.org, GCC Patches , rsandifo@nildram.co.uk, hp@gcc.gnu.org Subject: Re: Link tests after GCC_NO_EXECUTABLES References: <474C8FA4.2040603@codesourcery.com> <474C95BA.1060807@t-online.de> <474C96C1.7010208@codesourcery.com> <474C98AA.50105@t-online.de> <474C9A65.2060902@codesourcery.com> <474C9B33.8060503@t-online.de> <474C9CBD.2070708@codesourcery.com> <87fxyqdc45.fsf@firetop.home> <474D943C.4030106@codesourcery.com> <877ik0aerh.fsf@firetop.home> <20071130022132.GL17368@sygehus.dk> In-Reply-To: <20071130022132.GL17368@sygehus.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg01694.txt.bz2 Rask Ingemann Lambertsen wrote: >> Perhaps we should turn target-libgfortran off by default for mips*-elf*. > > No. There is a point in excercising the compiler: Testing. In most cases, > you don't find problems with the compiler until you try to compile something. When building the compiler and its libraries, testing is of incidental benefit; the primary goal is to build things. :-) The testsuite is for testing things. It's great to know that gfortran works for other ELF targets. That means that there must be something a bit odd in the MIPS support somewhere, and I'm sure we can find it and fix it. Thanks for working on the gfortran configure script. I think it would be great to make that work like the libstdc++ script. > This hunk should be left out. And I would prefer that we don't revert the > patch until everything that builds with the patch also builds without the > patch. I don't think that's necessary -- unless these things built with previous releases, in which case I'd be very concerned about making a change that caused fewer things to build. Did this work in 4.2? I don't know, but I'm expecting that it did not? It sounds like we upgraded libtool, and that introduced link-time tests into libstdc++, which caused build failures. So you came up with the top-level patch, which then probably made it possible to build some of the other target libraries that didn't build before for bare metal because they had always depended on link-time tests. Is that correct? We should be conservative about making changes in assumptions. If we're going to change the assumption that target library configure scripts cannot rely on link-time tests when $with_newlib is set, then let's do that consciously. I think it's reasonable to take that position (even though it's not my preference), but I don't want to change the assumption quietly. And, I think libstdc++ is our canonical model of a run-time library; others should follow its lead, until/unless we consciously decide otherwise. I also don't want to see each architecture or run-time library doing things in different ways. GCC's biggest strength is its cross-platform nature; we undermine that every time we do things in slightly different ways within our own individual areas of concentration. I'm in no way criticizing you or your top-level patch. I understand completely why you did what you did and its benefits. But, I want to get everyone on the same page, and until that happens, I want to stick with how things have been in the past. > Additionally, I would prefer we call the option something else than > --with-newlib - suppose there's no newlib for the target. At least the AVR > uses something else. That might be a good idea -- I think we do need to know which C library is in use for at least some of the target libraries. I'm pretty sure that libstdc++ actually depends on --with-newlib meaning that you're using Newlib (rather than some other C library) in that it uses facilities in Newlib that aren't necessarily part of a standard C library. I could be wrong about that, though. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713