From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id DF741385800F for ; Fri, 19 Nov 2021 10:57:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF741385800F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x10.wildebeest.org [172.31.17.146]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 90DBD302FBAF; Fri, 19 Nov 2021 11:57:14 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 58B052E83683; Fri, 19 Nov 2021 11:57:14 +0100 (CET) Date: Fri, 19 Nov 2021 11:57:14 +0100 From: Mark Wielaard To: "Dmitry V. Levin" Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH] tests: Add -ldl to dwfl_proc_attach_LDFLAGS Message-ID: References: <20211118212341.19077-1-mark@klomp.org> <20211118222026.GB2074@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211118222026.GB2074@altlinux.org> X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 10:57:17 -0000 Hi Dmitry, On Fri, Nov 19, 2021 at 01:20:26AM +0300, Dmitry V. Levin wrote: > On Thu, Nov 18, 2021 at 10:23:41PM +0100, Mark Wielaard wrote: > > dwfl-proc-attach uses (overrides) dlopen (so it does nothing). This > > seems to cause a versioned dlopen symbol to be pulled in when building > > with LTO. Resulting in a link failure (when dlopen isn't integrated > > into libc): > > > > /usr/bin/ld: dwfl-proc-attach.o (symbol from plugin): undefined > > reference to symbol 'dlopen@@GLIBC_2.2.5' > > /usr/bin/ld: /usr/lib64/libdl.so.2: error adding symbols: DSO missing > > from command line collect2: error: ld returned 1 exit status > > > > So simply explicitly add -ldl to the LDFLAGS. > [...] > Let's make clear what's going on here. First of all, dwfl-proc-attach.c > does not use dlopen so it doesn't pull it in and doesn't need -ldl. > In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so > which in turn uses dlopen and is already linked with -ldl. > When elfutils is configured with --enable-gprof or --enable-gcov, > BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with > ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread > which already contains -ldl. > In any case, I fail to understand why dwfl-proc-attach might need > an extra -ldl, especially in LDFLAGS which goes before LDADD > in the linking command. Agreed. It isn't totally clear why lto causes dlopen to be "pulled in" (which is probably the wrong technical term). But it really does. Instead of adding -ldl to LDFLAGS you can also remove the dlopen from the testcase: diff --git a/tests/dwfl-proc-attach.c b/tests/dwfl-proc-attach.c index d02e9fc0..0c5e8622 100644 --- a/tests/dwfl-proc-attach.c +++ b/tests/dwfl-proc-attach.c @@ -114,9 +114,5 @@ main (int argc __attribute__ ((unused)), So simply override dlopen and always return NULL so libdebuginfod (and libcurl) are never loaded. This test doesn't rely on libdebuginfod anyway. */ -void *dlopen (void) -{ - return NULL; -} #endif /* __linux__ */ Which also makes the linker happy, but removes the valgrind workaround. Cheers, Mark