From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80894 invoked by alias); 14 Apr 2019 23:16:45 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 80874 invoked by uid 89); 14 Apr 2019 23:16:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=ought, HTo:U*brian, H*r:sk:static., HX-HELO:sk:mail-pl X-HELO: mail-pl1-f178.google.com Received: from mail-pl1-f178.google.com (HELO mail-pl1-f178.google.com) (209.85.214.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 14 Apr 2019 23:16:44 +0000 Received: by mail-pl1-f178.google.com with SMTP id y6so7609605pll.13 for ; Sun, 14 Apr 2019 16:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AAV1zpN1qnOcUYJwa/RfGaH/iHf1nrUVVJ4rd1w/YbY=; b=sGC11AgFIYerQ2DdW/dymw1hxh+YwMN5o7Vnv0POY0QzQXivn4EH33hTw55Nm/KJP1 2H99tEA4TfAg6ULaVMiWjZjKlpzTS2IjQnLDct9pPz8B7iX1BsDGPUuzOc5EWajMDoGd KKCzQYqAxoyN3f/PTFyAbTZuUBtMlBdnlGpgm+/YQ0dmP1CTPTTm34BEacUvKUjbBoQL LoM3IgPShWpfQ8rci/cLBT5AawKuz/Ir8ABjWpLqKWO/ZJ1RS4xlID44Q+WREAc1f5IX 7JXTzJIyz702MzDaYSSL48Aka4TOLWH74cHMX9nt1qLkfKhiNR0TfEWZyO01S01Ji3T+ GRKQ== Return-Path: Received: from bubble.grove.modra.org (15.193.233.220.static.exetel.com.au. [220.233.193.15]) by smtp.gmail.com with ESMTPSA id l74sm76419224pfi.174.2019.04.14.16.16.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 14 Apr 2019 16:16:41 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id AF7A1805EE; Mon, 15 Apr 2019 08:46:37 +0930 (ACST) Date: Sun, 14 Apr 2019 23:16:00 -0000 From: Alan Modra To: Brian Groose Cc: binutils@sourceware.org Subject: Re: Linux ppc64 - compatibility-ldbl.o can't find std::num_put Message-ID: <20190414231637.GP14424@bubble.grove.modra.org> References: <20190413025656.GL14424@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00169.txt.bz2 On Sat, Apr 13, 2019 at 01:31:57PM -0400, Brian Groose wrote: > I have not yet tried newer versions of gcc, though that's my next step > as first I need 5.3.0. > > I did check, and the symbols are definitely in libstdc++.a (apologies > for the wrapping): > > $ nm -C /opt/act-gcc-5.3.0/lib64/libstdc++.a | grep -F > "std::ostreambuf_iterator > > std::num_put std::char_traits > > >::_M_insert_int(std::ostreambuf_iterator std::char_traits >, std::ios_base&, char, long) const" > U std::ostreambuf_iterator std::char_traits > std::num_put std::ostreambuf_iterator > > >::_M_insert_int(std::ostreambuf_iterator std::char_traits >, std::ios_base&, char, long) const > 0000000000001590 W std::ostreambuf_iterator std::char_traits > std::num_put std::ostreambuf_iterator > > >::_M_insert_int(std::ostreambuf_iterator std::char_traits >, std::ios_base&, char, long) const That ought to work fine. A weak undefined symbol doesn't cause the linker to extract an object that has a definition for the symbols, but you have a strong undefined symbol that does. I'd be just that little bit more happy if you weren't displaying demangled symbols since the linker works with the raw symbols, and were showing the object file names with "nm -o". > If I run 'ar x' for local-inst.o and wlocal-inst.o and add those two > .o files to my linker command line, it successfully links. OK, good. That excludes a whole lot of other possible problems. > My linker options, beyond local -L and -l for my own libraries, only > has -Wl,-z,noexecstack -static-libgcc -static-libstdc++. If I remove > -static-libstdc++, it does link successfully as well, though to the > shared version of course. > > I'm just not sure what would cause ld fail to find symbols that are in > the same .a but a different .o, I didn't think circular dependencies > between .o files in the same .a would cause this type of issue as can > happen when two .a files depend on each other. Yes, that should be OK. When the linker extracts compatibility-ldbl.o from libstdc++.a it will notice this object adds more undefined symbols. That triggers a rescan over the archive. > Is there a table or > index that might not be updated, as was the case in that previous bug? Well, you could try running ranlib from your new binutils on libstdc++.a. ranlib creates the symbol map to object table in archives used by the linker to decide which objects should be extracted. -- Alan Modra Australia Development Lab, IBM