From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from isrv.corpit.ru (isrv.corpit.ru [86.62.121.231]) by sourceware.org (Postfix) with ESMTPS id 867D03858D28 for ; Sat, 26 Mar 2022 15:06:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 867D03858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tls.msk.ru Authentication-Results: sourceware.org; spf=none smtp.mailfrom=tls.msk.ru Received: from tsrv.corpit.ru (tsrv.tls.msk.ru [192.168.177.2]) by isrv.corpit.ru (Postfix) with ESMTP id 7FB81409C4; Sat, 26 Mar 2022 18:06:27 +0300 (MSK) Received: from [192.168.177.130] (mjt.wg.tls.msk.ru [192.168.177.130]) by tsrv.corpit.ru (Postfix) with ESMTP id 9DAB936F; Sat, 26 Mar 2022 18:02:40 +0300 (MSK) Message-ID: Date: Sat, 26 Mar 2022 18:06:26 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: puzzling ld behavior, failing to find symbols from .so after adding more .o file Content-Language: en-US To: Andrew Pinski Cc: binutils References: From: Michael Tokarev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2022 15:06:28 -0000 26.03.2022 03:25, Andrew Pinski wrote: > > One thing to try is to add -Wl,--no-as-needed (and remove > -Wl,--as-needed) and see if that helps. adding --no-as-needed to the beginning and removing --as-needed at the end does not change anything. > My bet is there are some ordering issues. in my tests, I add independent object files to the link line one by one. More, I keep all the -lfoo at their places, - in order to replace libfooo.so with libfoo.a, I *remove* libfoo.so file, so the linker finds only the .a variant. All the other stuff is here, order stays the same. .. >> /usr/bin/ld: ./bin/default/../../source3/lib/dbwrap/dbwrap_ctdb.c:1639: undefined reference to `tdb_null' >> /usr/bin/ld: source3/lib/dbwrap/dbwrap_ctdb.c.45.o: relocation R_X86_64_PC32 against undefined hidden symbol `tdb_null' can not be used when making a >> shared object Someone on the IRC told me this: R_X86_64_PC32 is is a relocation required to be local to the module. Note it's not GOT-relative. you need to check how tdb_null is declared when it's compiled I don't know what is a relocation required to be local or what is GOT-relative. But I do know there are several different possibilities for libtdb compilation. The thing is: it is samba, and the libraries in question are libraries internal to samba, which were built separately, and samba is told to use system version of these libs. Maybe the whole thing is because the build "mixes" system libs and internal headers with different symbol flags/definitions? So far, it *seems* the whole thing breaks once I add any .o file which uses tdb.h/libtdb. Not yet sure about this, since I can't add any object file into the mix due to inter-object-file deps (so I'm adding only the simplest self-contained ones), but all self-containing tdb-using ones gives this surprize result. Where one can see which variant of the symbol an object file wants compared to the variant which is provided by an .so file? Which variants are possible? Thank you! /mjt