From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21532 invoked by alias); 30 Nov 2007 02:21:49 -0000 Received: (qmail 21510 invoked by uid 22791); 30 Nov 2007 02:21:48 -0000 X-Spam-Check-By: sourceware.org Received: from pfepa.post.tele.dk (HELO pfepa.post.tele.dk) (195.41.46.235) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Nov 2007 02:21:40 +0000 Received: from x1-6-00-0f-9f-c6-3e-90 (x1-6-00-0f-9f-c6-3e-90.k75.webspeed.dk [80.197.1.215]) by pfepa.post.tele.dk (Postfix) with ESMTP id 464C1FAC017; Fri, 30 Nov 2007 03:21:37 +0100 (CET) Received: from x1-6-00-0f-9f-c6-3e-90 (localhost.localdomain [127.0.0.1]) by x1-6-00-0f-9f-c6-3e-90 (8.14.0/8.14.0) with ESMTP id lAU2LauC019513; Fri, 30 Nov 2007 03:21:36 +0100 Received: (from rask@localhost) by x1-6-00-0f-9f-c6-3e-90 (8.14.0/8.14.0/Submit) id lAU2LYpv019512; Fri, 30 Nov 2007 03:21:34 +0100 Date: Fri, 30 Nov 2007 09:58:00 -0000 From: Rask Ingemann Lambertsen To: Mark Mitchell , 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 Message-ID: <20071130022132.GL17368@sygehus.dk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877ik0aerh.fsf@firetop.home> User-Agent: Mutt/1.5.14 (2007-02-12) 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/msg01690.txt.bz2 On Thu, Nov 29, 2007 at 10:05:54PM +0000, Richard Sandiford wrote: > Even though current mainline can build libgfortran, all tests fail for > simulator testing, and I'm not sure whether you could get it work for > bare-metal boards or not. It works on arm-unknown-elf, v850-unknown-elf and frv-unknown-elf: http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01428.html http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01468.html http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00427.html Some work has been and is being done in this area: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185 Hans, you showed gfortran results for cris-elf, but we don't seem to be building gfortran for the cris? > It sounds like we've agreed that, if we want > to support libgfortran on targets like mips*-elf*, we should use > libstd++-like with_newlib checks there too. Likewise for the other target libraries - how many did you test? I tried a build of sparc-unknown-elf (which is know to fail link tests) with "with_newlib" checks around the AC_LIBTOOL_DLOPEN macro in both libstdc++ and libgfortran. It fails because: configure:3391: checking whether symbol versioning is supported configure:3402: error: Link tests are not allowed after GCC_NO_EXECUTABLES. With this patch I get marginally further: Index: libgfortran/configure.ac =================================================================== --- libgfortran/configure.ac (revision 130442) +++ libgfortran/configure.ac (working copy) @@ -142,12 +142,14 @@ global: *foo*; bar; local: *; }; EOF -save_LDFLAGS="$LDFLAGS" -LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map" -AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no]) -LDFLAGS="$save_LDFLAGS" -AC_MSG_RESULT($gfortran_use_symver) -AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes]) +if test "x${with_newlib}" != "xyes"; then + save_LDFLAGS="$LDFLAGS" + LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map" + AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no]) + LDFLAGS="$save_LDFLAGS" + AC_MSG_RESULT($gfortran_use_symver) + AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes]) +fi # Find other programs we need. AC_CHECK_TOOL(AS, as) @@ -158,7 +160,9 @@ # Configure libtool #AC_MSG_NOTICE([====== Starting libtool configuration]) -AC_LIBTOOL_DLOPEN +if test "x${with_newlib}" != "xyes"; then + AC_LIBTOOL_DLOPEN +fi AM_PROG_LIBTOOL AC_SUBST(enable_shared) AC_SUBST(enable_static) configure:18061: checking for getrusage configure:18067: error: Link tests are not allowed after GCC_NO_EXECUTABLES. > 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. > @@ -2410,6 +2368,16 @@ fi > > # Search for other target-specific linker scripts and such. > case "${target}" in > + m32c-*-* ) > + if test -d ${srcdir}/libgloss/m32c; then > + # This is for crt0.o > + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$$r/$(TARGET_SUBDIR)/libgloss/m32c' > + # This is for r8c.ld > + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/m32c' > + # This is for libnosys.a > + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys' > + fi > + ;; > mep*) > FLAGS_FOR_TARGET="$FLAGS_FOR_TARGET -mlibrary" > ;; 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. 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. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year