From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13328 invoked by alias); 16 Nov 2009 22:47:03 -0000 Received: (qmail 13304 invoked by uid 22791); 16 Nov 2009 22:47:02 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from vsmtp3.tin.it (HELO vsmtp3.tin.it) (212.216.176.223) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 22:45:58 +0000 Received: from [192.168.0.4] (79.52.192.133) by vsmtp3.tin.it (8.5.113) id 4AE18BD901D7DE92; Mon, 16 Nov 2009 23:45:42 +0100 Message-ID: <4B01D615.8070700@oracle.com> Date: Mon, 16 Nov 2009 22:48:00 -0000 From: Paolo Carlini User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ralf Wildenhues , Matthias Klose , Paolo Carlini , "libstdc++@gcc.gnu.org" , Richard Earnshaw , Andrew Haley , Jakub Jelinek , Alexandre Oliva , Nathan Froyd , GCC Patches , GCJ-patches Subject: Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc References: <4ABB30DE.6050502@redhat.com> <4ABB3BE6.4060800@ubuntu.com> <4ABB4C9B.3070200@redhat.com> <1255527525.4842.29.camel@e200601-lin.cambridge.arm.com> <4ADF0B67.9070505@ubuntu.com> <4AEA2FF1.6060508@ubuntu.com> <4AEA3318.6060607@oracle.com> <4AEF025A.5060403@ubuntu.com> <4AEF08BF.4020500@oracle.com> <4AFC5187.2010909@ubuntu.com> <20091116223035.GA12513@gmx.de> In-Reply-To: <20091116223035.GA12513@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2009-11/txt/msg00818.txt.bz2 Ralf Wildenhues wrote: > What would you suggest as the algorithm to fix it in libtool? > Mind you, I've probably forgotten parts of this, so please bear > with me: > > Should libtool always reorder -lgcc_s before -lgcc if it sees > (or is to emit) both? On all systems? If not, on which? > Which of the two should it reorder, and where, if the two do > not occur successively? What if another library dependency > drags in one but not the other, and we already have seen one > or both? > > FWIW, I never saw a workable approach fixing libtool only, > nor understood how libtool could be fixed consistently. > If you are confident that *all* the linux targets at the moment are fine, you can as well hardcode in the library configure that knowledge and skip running the configure test for those. However, if you want to put in place the looser configure check, you must be 100% sure that it also works correctly on anything != linux, and that means, per Joseph' comments, making sure those generic compiler bits about linking the static libgcc are properly implemented. Either of those is fine with me. Paolo