From patchwork Wed Dec 19 15:38:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Klose X-Patchwork-Id: 207408 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 9F2A02C0097 for ; Thu, 20 Dec 2012 02:38:49 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1356536329; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=fe3LERaS+LwMwwMk4ZRV QvYHJkI=; b=ZiHUWDMBUei8kk/cXpHY+BjAc5ar4ndQg8B+FvtduLhI6D3A9SpO EU+Kw8eMzhp2ivqQlq7SxOad8rOKxwXYCNPWIBMbP/ArTmD2xM++xPgODYKzwHW9 hyL3dS2XiZt89xHbFEalFylshmlf/wvtRMqRHAiqOwJCHyPtih6mRQk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=uwJ5YhdY223aGRt+sJ0RVYRURORc5jkplCENbK4UOIqe1LmWt2Id7JKxSOnJpM x9Y5yJZd63F/D3ASAtTqu/gMeFwjVmfqGMfwpU6N66upj1jq9eoAUw4JARGqEPSS QmfhqGA6Xe/FFdvTPX+NYWkE80Yi8A12hXDMjzGoi4oPg=; Received: (qmail 4792 invoked by alias); 19 Dec 2012 15:38:42 -0000 Received: (qmail 4775 invoked by uid 22791); 19 Dec 2012 15:38:41 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, TW_BG, TW_BJ, TW_IB X-Spam-Check-By: sourceware.org Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Dec 2012 15:38:30 +0000 Received: from dslb-088-073-108-045.pools.arcor-ip.net ([88.73.108.45] helo=[192.168.42.216]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1TlLj1-0001SQ-1c; Wed, 19 Dec 2012 15:38:27 +0000 Message-ID: <50D1DF6F.5060109@ubuntu.com> Date: Wed, 19 Dec 2012 16:38:23 +0100 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ian Lance Taylor CC: Richard Henderson , Andreas Schwab , gcc-patches@gcc.gnu.org Subject: Re: PATCH RFA: PR go/55201: Create libatomic convenience library References: <50D0E0F2.5090407@redhat.com> <50D0EE7E.6000702@redhat.com> <50D0F920.8020703@redhat.com> In-Reply-To: Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Am 19.12.2012 01:28, schrieb Ian Lance Taylor: > On Tue, Dec 18, 2012 at 3:15 PM, Richard Henderson wrote: >> On 12/18/2012 02:52 PM, Ian Lance Taylor wrote: >>> Argh. But why? Wouldn't that only apply to cases where the lock was >>> sometimes locked by one library and sometimes locked by a different >>> one? >> >> Or did you really mean >> >> "... only apply to cases where the memory protected by the lock >> was visible to more than one library." >> >> Yes, if libgo is attempting atomic accesses to its own data structures, >> which themselves are not exported from libgo, then a copy of libatomic >> ought to work. >> >> It would probably be better for the shared libgo to depend on the >> shared libatomic though. That's simply more pedantically correct. > > But according to Matthias's comment upthread, it would require > addressing some issue in libtool in order to get multilib working > correctly. > > I'm not going to try to solve this today, but if somebody else wants > to that would be great. you cannot reproduce this, if you already have libatomic.so.1 installed into your destination/installation path. You should be able to reproduce this by installing into an empty destination (maybe using DESTDIR). Then libgo can't find the libatomic. calling make install-target-libatomic and then re-running lets make install succeed. Makefile.def doesn't define any dependencies on the installation targets, however seldom people run make install with -j, and then the order the target_modules are listed matters. libatomic comes behind the libgo target, otoh libquadmath comes before libgfortran and installs without issues. The following patch fixes this for me, maybe other target library dependencies should be added too. that would be for libgfortran on libquadmath, libgcc libsanitizer on libstdc++ libstdc++ on libgomp, libgcc libjava on libstdc++, libgcc libasan on libgcc libobjc on libgcc libitm on libgcc Matthias Index: Makefile.def =================================================================== --- Makefile.def (Revision 194604) +++ Makefile.def (Arbeitskopie) @@ -514,6 +514,8 @@ // recursive make, we can't be that specific. dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp; }; +dependencies = { module=install-target-libgo; on=install-target-libatomic; }; + // Target modules in the 'src' repository. lang_env_dependencies = { module=libtermcap; }; lang_env_dependencies = { module=rda; };