From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 3F497385800C for ; Fri, 19 Nov 2021 16:58:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F497385800C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-371-4BxLyhC5PAiM-wN1vHmErw-1; Fri, 19 Nov 2021 11:58:23 -0500 X-MC-Unique: 4BxLyhC5PAiM-wN1vHmErw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58DAB9F92B; Fri, 19 Nov 2021 16:58:22 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5F49F1972E; Fri, 19 Nov 2021 16:58:21 +0000 (UTC) From: Florian Weimer To: "Dmitry V. Levin" Cc: Mark Wielaard , elfutils-devel@sourceware.org Subject: Re: [PATCH] tests: Add -ldl to dwfl_proc_attach_LDFLAGS References: <20211118212341.19077-1-mark@klomp.org> <20211118222026.GB2074@altlinux.org> Date: Fri, 19 Nov 2021 17:58:19 +0100 In-Reply-To: <20211118222026.GB2074@altlinux.org> (Dmitry V. Levin's message of "Fri, 19 Nov 2021 01:20:26 +0300") Message-ID: <87czmwaxqs.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 16:58:26 -0000 * Dmitry V. Levin: > 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. It may have to do with --as-needed that some builds use. If there are no pending undefined references, some linkers drop earlier shared object references with --as-needed (similar to what happens with static archives). The GCC LTO plugin results in ld looking at more objects in greater detail for some reason. Without LTO and --as-needed, you probably don't get a dlopen export (if you do not link with -E) because indirect dependencies are not consulted, breaking the valgrind workaround because there is no interposition. Thanks, Florian