From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20117 invoked by alias); 26 Aug 2015 11:48:04 -0000 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 Received: (qmail 20087 invoked by uid 89); 26 Aug 2015 11:48:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 26 Aug 2015 11:48:01 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 26 Aug 2015 12:47:11 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 26 Aug 2015 12:46:16 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gcc-patches@gcc.gnu.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 0BB0017D8075; Wed, 26 Aug 2015 12:47:36 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t7QBjsGU34340866; Wed, 26 Aug 2015 11:45:57 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t7QBjiYB020956; Wed, 26 Aug 2015 05:45:44 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-24.boeblingen.de.ibm.com [9.152.213.24]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t7QBjiLO020693; Wed, 26 Aug 2015 05:45:44 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 50D0C24DD; Wed, 26 Aug 2015 13:45:35 +0200 (CEST) Subject: Re: Fix libbacktrace -fPIC breakage from "Use libbacktrace in libgfortran" To: hans-peter.nilsson@axis.com (Hans-Peter Nilsson) Date: Wed, 26 Aug 2015 12:17:00 -0000 From: "Ulrich Weigand" Cc: ian@airs.com, fxcoudert@gmail.com, gcc-patches@gcc.gnu.org, ubizjak@gmail.com, fortran@gcc.gnu.org In-Reply-To: <201508252333.t7PNX1xG011553@ignucius.se.axis.com> from "Hans-Peter Nilsson" at Aug 26, 2015 01:33:01 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150826114535.50D0C24DD@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15082611-0009-0000-0000-00000554E383 X-SW-Source: 2015-08/txt/msg01596.txt.bz2 Hans-Peter Nilsson wrote: > > From: Ulrich Weigand > > Date: Tue, 25 Aug 2015 19:45:06 +0200 > > > However, neither works for the SPU, because in both cases libtool > > will only do the test whether the target supports the -fPIC option. > > It will not test whether the target supports dynamic libraries. > > > > [ It will do that test; and default to --disable-shared on SPU. > > That is a no-op for libbacktrace however, since it calls LT_INIT > > with the disable-shared option anyway. > > Maybe it shouldn't? Huh? We do want libbacktrace solely as static library, that's the whole point ... > > When adding back the -fPIC > > flag due to either the pic-only LT_INIT option or the -prefer-pic > > libtool command line option, it does not check for that again. ] > > Sounds like a bug somewhere, in libtool or its current use: > there *should* be a way to specify "I'd prefer PIC code in these > static libraries". But that's what the option *does*. Let me try again, maybe we can reduce confusion a bit :-) We've been discussing three potential sets of options to use with the LT_INIT call here. Those are: A) LT_INIT # no options Build both a static and a shared library. If the target does not support shared libraries, build the static library only. The code landing in the static library is built without -fPIC; code for the shared library is built with -fPIC (or the appropriate target flag). B) LT_INIT([disable-shared]) Build *solely* a static library. Code is compiled without -fPIC. C) LT_INIT([disable-shared,pic-only]) Build solely a static library, but compile code with -fPIC or the appropriate target flag (may be none if the target does not support -fPIC). [Note that in all cases, behaviour can be overridden via configure options like --enable/disable-shared and --enable/disable-static.] As I understand it, we deliberately do not use option A. As the comment in the libbacktrace configure.ac says: # When building as a target library, shared libraries may want to link # this in. We don't want to provide another shared library to # complicate dependencies. Instead, we just compile with -fPIC. That's why libbacktrace currently uses option B and manually adds a -fPIC flag. Now, after the latest check-in, the behaviour is mostly equivalent to using option C (and not manually changing PIC flags). However, none of the options do exactly what would be right for the SPU, which would be: Build solely a static library, using code that is compiled so that it can be linked as part of a second library (static or shared). This is equivalent to: Build solely a static library, but compile code with -fPIC or the appropriate target flag *if the target supports shared libraries*. This again is *mostly* equivalent to option C, *except* on targets that support -fPIC but do not support shared libraries. I'm not sure if it is worthwhile to try and change libtool to support targets with that property (e.g. adding a new LT_INIT option), if this in practice only affects SPU. > But, I'll have to leave solving this PIC-failing-at-linkage > problem to you; I committed the current approved fix for > PIC-failing-at-compilation. I guess we can always fall back to just hard-coding SPU once more; that's certainly the simplest solution right now. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com