From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9964 invoked by alias); 5 May 2011 09:23:51 -0000 Received: (qmail 9948 invoked by uid 22791); 5 May 2011 09:23:50 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_FAIL,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mail-n.franken.de (HELO mail-n.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 09:23:36 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) by mail-n.franken.de (Postfix) with ESMTP id 947001C0B4611; Thu, 5 May 2011 11:23:35 +0200 (CEST) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 08D3526C07E; Thu, 5 May 2011 11:23:35 +0200 (CEST) Received: by calimero.vinschen.de (Postfix, from userid 500) id DE5932C0578; Thu, 5 May 2011 11:23:34 +0200 (CEST) Date: Thu, 05 May 2011 09:24:00 -0000 From: Corinna Vinschen To: Ulrich Weigand Cc: newlib@sourceware.org, gcc-patches@gcc.gnu.org, yselkowitz@users.sourceforge.net, dj@redhat.com, ken.werner@de.ibm.com Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms) Message-ID: <20110505092334.GA16123@calimero.vinschen.de> Mail-Followup-To: Ulrich Weigand , newlib@sourceware.org, gcc-patches@gcc.gnu.org, yselkowitz@users.sourceforge.net, dj@redhat.com, ken.werner@de.ibm.com References: <20110504111745.GD26180@calimero.vinschen.de> <201105050909.p4599SUA010092@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201105050909.p4599SUA010092@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-05/txt/msg00387.txt.bz2 On May 5 11:09, Ulrich Weigand wrote: > This list does not include psignal, which indeed newlib did not provide > -- until yesterday, when that patch was committed ... > > > I'm not quite sure how to fix this ... any suggestions? Did this problem > occur in the past when newlib was extended to provide some new function? > > I guess the immediate build problem will disappear once the libiberty > prototype is fixed to include const, but then we'll just have two copies > of psignal (one in newlib, one in libiberty), which may not be ideal > either. Developers using libiberty don't have to use newlib so the definition in libiberty still makes sense, right? I don't know how to avoid this problem in configure, other than by adding AC_LIBOBJ([psignal]). Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat