From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mVhIGe9pHGDUCwAAWB0awg (envelope-from ) for ; Thu, 04 Feb 2021 16:41:03 -0500 Received: by simark.ca (Postfix, from userid 112) id 5A15B1EFCB; Thu, 4 Feb 2021 16:41:03 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9E87F1E945 for ; Thu, 4 Feb 2021 16:41:02 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F1E4639D2C64; Thu, 4 Feb 2021 21:41:01 +0000 (GMT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by sourceware.org (Postfix) with ESMTPS id 6BA1F39D2C62 for ; Thu, 4 Feb 2021 21:40:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6BA1F39D2C62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=casner@acm.org Received: from auge (75-25-121-24.lightspeed.snvaca.sbcglobal.net [75.25.121.24]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 114Leo2J013315 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 4 Feb 2021 13:40:52 -0800 Date: Thu, 4 Feb 2021 13:40:49 -0800 (PST) From: Stephen Casner To: Nick Alcock Subject: Re: new gdb build failures on MacOS X (... fallout from libintl fixups, see users/nalcock/included-gettext) In-Reply-To: <87k0rna7w4.fsf_-_@esperi.org.uk> Message-ID: References: <874kird819.fsf@esperi.org.uk> <87k0rna7w4.fsf_-_@esperi.org.uk> User-Agent: Alpine 2.21.9999 (OSX 301 2018-08-15) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Sonic-CAuth: UmFuZG9tSVYqOptyzJdnZYs1dNlthhtcTdihc3d5y+StwjU7OQTiSnU+uoVLOpSIO26QaGgBA9s6pll0a/2xlFVIAFJvIGLv X-Sonic-ID: C;0NxnpjFn6xGX0Z3Pl+vPsg== M;3oNrpzFn6xGX0Z3Pl+vPsg== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Thu, 4 Feb 2021, Nick Alcock wrote: > On 4 Feb 2021, Stephen Casner told this: > > To satisfy those I need to hack the gdb/Makefile to append > > /usr/lib/libiconv.dylib (the system libiconv, which is old) after two > > instances of -liconv. If I replace -liconv rather than appending then > > I get three different undefined symbols: > > Hmm, so -liconv isn't loading /usr/lib/libiconv.dylib? Sorry, I missed saying that -liconv gets /opt/local/lib/libiconv.{a,dylib} which is the more current one that I installed. I'm not sure how that one is found. I have tried --with-libiconv-prefix=/opt/local but, as I mentioned, that causes -I./../intl to be removed from the bfd compiles. > The -L stuff I tore out of libopcodes and bfd (which might be relevant) > is -L`pwd`/../libiberty/pic -L`pwd`/../intl -liberty -lintl, which also > does not explicitly cite libiconv. (The libiberty stuff is brought back > in a bit further up, and the intl stuff should be retained via > $(LTLIBINTL) as well.) > > > "_libiconv", referenced from: > > Oh wonderful. _iconv *and* _libiconv? Right. So I presume one of the libraries links with one of them and the main links with the other. > > So the gdb link requires two different iconv libraries presumably > > because different parts of the build choose different references. > > Looks like it. A full log of the compilation of gdb/ at least (and > preferably the whole build) might give more info about which bits are > using what. I will follow up on that. > > been trying to figure out how to fix this properly but so far I have > > not gained enough familiarity with the configure and Makefile morass > > to find the answer. There is a --with-libiconv-prefix option for gdb, > > but when I include that it causes -I./../intl to be removed from the > > compile commands for bfd > > Yeah, intl/ also has --with-libiconv-prefix, which is probably > triggering this -- though that just sets --prefix for the intl/ tree, > which I wouldn't really expect to cause this (but I've never tried that > option, so I'm not sure). I'll try looking more there, too. I should also point out that the native compile on macOS does not build as or ld for reasons that I don't yet understand. So I should probably test your branch for my cross pdp11 build as well. That one does not build gdb (since it would never fit in the 16-bit address space). -- Steve