From patchwork Mon May 7 11:23:50 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 157292 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 604ADB6FAB for ; Mon, 7 May 2012 21:24:13 +1000 (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=1336994654; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=SZHjt/S1zKDzLScx+fthn4jBa14=; b=cIKJmXzHGmbiDA6 eTknYqNvwNq6TAtte+CJ6sw9Fo7d7bi9OHGS0/xsn70xFq3vt0JbxRd8N05Vj1wr gPLv6zoXeYJZs5MtEWL4mBxaWrn0fLews0pDEc0usyoZhYI6igkluKiHYBzlHNxj GUltZ8b3Ly1jHdCIm19GVG8xyxeU= 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:Received:Received:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=mUNVVVRryNmp9t1rNw9ld/nkEzcztqHLjNU+nqg8jUPvnqksGywjPuNZanLM6d pvNE7mQdbuxh3p0BpUSFfVfQg1XX/Hr20e3MiUECZNswHuTn8JAF/aNR2YeICQXM xcPumUFPquTOVN/Mo9oiY6moZrRsV8os2DlYuajJUOmzk=; Received: (qmail 3877 invoked by alias); 7 May 2012 11:24:09 -0000 Received: (qmail 3868 invoked by uid 22791); 7 May 2012 11:24:08 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, TW_IB, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS X-Spam-Check-By: sourceware.org Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 May 2012 11:23:55 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 8C5CA8CB; Mon, 7 May 2012 13:23:54 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n25-a8iNyKhr; Mon, 7 May 2012 13:23:50 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (manam.CeBiTec.Uni-Bielefeld.DE [129.70.161.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id D589F8CA; Mon, 7 May 2012 13:23:50 +0200 (CEST) Received: (from ro@localhost) by manam.CeBiTec.Uni-Bielefeld.DE (8.14.5+Sun/8.14.5/Submit) id q47BNoh8018116; Mon, 7 May 2012 13:23:50 +0200 (MEST) From: Rainer Orth To: gcc-patches@gcc.gnu.org Cc: Richard Henderson Subject: [libatomic] Allow for objects in libatomic_la_LIBADD Date: Mon, 07 May 2012 13:23:50 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (usg-unix-v) MIME-Version: 1.0 X-IsSubscribed: yes 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 After the previous libatomic patch, many testcases fail on Solaris/x86 like this: FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors) Excess errors: Undefined first referenced symbol in file __atomic_compare_exchange_1 /var/tmp//cc7jayIi.o ld: fatal: symbol referencing errors. No output written to . WARNING: libatomic.c/atomic-compare-exchange-1.c compilation failed to produce executable This is caused by the fact that the libatomic.map-sun rule currently only expects archives in libatomic_la_LIBADD, but here it contains objects instead. This is a great demonstration why the current massive duplication of such rules among versioned libraries is a mess: the libjava rules had this right. Unifying all this is still on my agenda. The following patch fixes this and fixes all but a few testcases which fail for unrelated reasons (yet to be determined/reported). I've not only regenerated Makefile.in, but also aclocal.m4, since automake complained configure.ac:84: version mismatch. This is Automake 1.11.1, configure.ac:84: but the definition used by this AM_INIT_AUTOMAKE configure.ac:84: comes from Automake 1.11.3. You should recreate configure.ac:84: aclocal.m4 with aclocal and run automake again. and 1.11.1 is the current required version. Ok for mainline? Rainer 2012-05-05 Rainer Orth * Makefile.am (libatomic.map-sun): Handle objects in libatomic_la_LIBADD. * aclocal.m4: Regenerate. * Makefile.in: Regenerate. # HG changeset patch # Parent 0114ed05eb41c51370fdc050784072611a025da8 Allow for objects in libatomic_la_LIBADD diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am --- a/libatomic/Makefile.am +++ b/libatomic/Makefile.am @@ -56,7 +56,7 @@ libatomic.map-sun : $(top_srcdir)/libato $(top_srcdir)/libatomic.map \ $(libatomic_la_OBJECTS:%.lo=.libs/%.o) \ `echo $(libatomic_la_LIBADD) | \ - sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ + sed 's,\([^/ ]*\)\.l\([ao]\),.libs/\1.\2,g'` \ > $@ || (rm -f $@ ; exit 1) endif else