From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14686 invoked by alias); 5 May 2011 16:44:37 -0000 Received: (qmail 14650 invoked by uid 22791); 5 May 2011 16:44:36 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate2.uk.ibm.com (HELO mtagate2.uk.ibm.com) (194.196.100.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 16:44:13 +0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p45GiBR6006787 for ; Thu, 5 May 2011 16:44:11 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p45GjOIW2564294 for ; Thu, 5 May 2011 17:45:24 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p45GiBYU002995 for ; Thu, 5 May 2011 10:44:11 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p45Gi9r2002979; Thu, 5 May 2011 10:44:10 -0600 Message-Id: <201105051644.p45Gi9r2002979@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 05 May 2011 18:44:09 +0200 Subject: Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms) To: dj@redhat.com (DJ Delorie) Date: Thu, 05 May 2011 16:54:00 -0000 From: "Ulrich Weigand" Cc: vinschen@redhat.com (Corinna Vinschen), newlib@sourceware.org, gcc-patches@gcc.gnu.org, yselkowitz@users.sourceforge.net, ken.werner@de.ibm.com In-Reply-To: <201105051529.p45FTenR013590@greed.delorie.com> from "DJ Delorie" at May 05, 2011 11:29:40 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00436.txt.bz2 DJ Delorie wrote: > > I don't know how to avoid this problem in configure, other than by adding > > AC_LIBOBJ([psignal]). > > Right, the correct solution is - libiberty shouldn't provide psignal > if newlib does. Making it match newlib is the wrong solution. I guess I agree, but the problem is exactly how to implement "if newlib does" ... Usually, this would be a link test, which libiberty configure deliberately avoids for cross-builds, so it hardcodes "what newlib does". Do you suggest we should do the link test after all, or make the hard- coded newlib capability list somehow dynamic (depending on what)? Maybe I'm missing something, but I don't understand the AC_LIBOBJ suggestion. This would add "psignal.o" to the list of object files to be linked into libiberty. But: 1.) there is no psignal.o / psignal.c in libiberty, but the symbol psignal is defined within strsignal.c; and 2.) strsignal.o is already added unconditionally to the list of libiberty objects ... [ But even if we *did* split psignal into its own object file, that would still not answer the question of when to link it in and when not. ] Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com