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 7FA493858D28 for ; Sat, 26 Mar 2022 15:19:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FA493858D28 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 47376409C4; Sat, 26 Mar 2022 18:19:23 +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 5589236F; Sat, 26 Mar 2022 18:15:36 +0300 (MSK) Message-ID: <7f94bd18-ff3e-d3de-d3a6-1568a0b3709c@msgid.tls.msk.ru> Date: Sat, 26 Mar 2022 18:19:21 +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 From: Michael Tokarev To: Andrew Pinski Cc: binutils References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 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:19:24 -0000 26.03.2022 18:06, Michael Tokarev wrote: .. >>> /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. I think I got it sorted out. in the new version the tdb.h file (which declares tdb_null and other stuff) added _PUBLIC_ attribute before all symbols, which is by default evaluates to attribute(visibility(default)). But when compiling samba, _PUBLIC_ is defined to attribute(visibility(hidden)) before including tdb.h. And things goes the wrong way from here... It is interesting still why ld behaves this way, but the mystery is now solved. Thanks, /mjt