From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18270 invoked by alias); 19 Dec 2012 00:28:28 -0000 Received: (qmail 18261 invoked by uid 22791); 19 Dec 2012 00:28:27 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com) (209.85.219.45) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Dec 2012 00:28:22 +0000 Received: by mail-oa0-f45.google.com with SMTP id i18so1369376oag.4 for ; Tue, 18 Dec 2012 16:28:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Vnir61iXV5kUvI8+T7BxFQLPqiAyeeVB//35dDXJqzE=; b=AHjuorX0S21MpjKZKVJrKHNHKtjXJiQ4d2zyH/HgN5LzTD6IJ5WsaLre7BrFnMWEDZ HbGp/Xb90cUhVE4etVF1p7fDsKjA4cwAcpSVXfQaisIKqshFYwvu7MBwXise9wXZepg+ iEAzVgPc3srFX/IYV7jH625DxfAFUB64mnrqIrbKeaEtSaxhUoK6gb9NIn2Wd9llCvEv QgKRgB9ZJppbCNb7XBFi25WJFxyo16J27JlBPGxFP5N+EZOLBXzVQZ0yLCMeLUT04Zt/ DA290HHx3H2IE+KxR8HkZyFuraLsY+KT0979tQ2A3G6dDzdDoyG2uTQLnORirVbS4r2o IRYQ== MIME-Version: 1.0 Received: by 10.60.32.73 with SMTP id g9mr3347143oei.134.1355876901624; Tue, 18 Dec 2012 16:28:21 -0800 (PST) Received: by 10.182.115.72 with HTTP; Tue, 18 Dec 2012 16:28:21 -0800 (PST) In-Reply-To: <50D0F920.8020703@redhat.com> References: <50D0E0F2.5090407@redhat.com> <50D0EE7E.6000702@redhat.com> <50D0F920.8020703@redhat.com> Date: Wed, 19 Dec 2012 00:28:00 -0000 Message-ID: Subject: Re: PATCH RFA: PR go/55201: Create libatomic convenience library From: Ian Lance Taylor To: Richard Henderson Cc: Matthias Klose , Andreas Schwab , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmvU2VWVgxEwkd1gD7nrY6eplGxKofKHcVWSmxzqadjUmQSJ9KBv/epnQypj3gWwuUtihAaxWQ7gjcWHWWuyMSs/X9t5w+6cw3+C8+ru+oXDtvc5p7ke8hReMeOfgCsUlA7QXQKQVI6Ba4znQOlUbfnuZK8atckcC+g8fW8+SzODQmDZOiQEyn9SiI1tW+QUefN1StE 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: 2012-12/txt/msg01164.txt.bz2 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. Ian