From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23461 invoked by alias); 21 Feb 2020 16:02:24 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 23442 invoked by uid 89); 21 Feb 2020 16:02:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=misunderstood X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Feb 2020 16:02:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582300941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qbrkSKp1x1cRTjx1bUBMRBPvbdsHqNXFAC9ObtDG5nw=; b=S+Yt7/RA1zt9tmtZ0vBL2N2wHxY0pYKmNBBMEC3C0j6tpnsRN8MBhcsH0JcGH26tbgre6A sKp0jV1tPShdcU8GPzRbAPLjYWSv9g9xGodRVBbV1J9Pa+W+U/51EPSblE5u8a7nfYjDFy bj6BEuRjnf7PPYF/+vCf+LgDC8u/jDo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-58-NZ2slJn3Nmm2CNxR4znJzQ-1; Fri, 21 Feb 2020 11:02:19 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3F376100DFF3 for ; Fri, 21 Feb 2020 16:02:18 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04D7F9051B; Fri, 21 Feb 2020 16:02:14 +0000 (UTC) From: Florian Weimer To: "Richard W.M. Jones" Cc: Eric Blake , libc-help@sourceware.org, "libguestfs\@redhat.com" Subject: Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT? References: <8cf57641-c31e-3db5-49af-d9d7407a9cb8@redhat.com> <39d94f06-5793-16b5-1372-df3248924671@redhat.com> <3ee96b3f-231b-737f-299a-4406f108c30f@redhat.com> <87d0adnt84.fsf@oldenburg2.str.redhat.com> <8736b4jfop.fsf@oldenburg2.str.redhat.com> <20200221145132.GK7304@redhat.com> <87d0a8dlyp.fsf@oldenburg2.str.redhat.com> <20200221153958.GP3888@redhat.com> Date: Fri, 21 Feb 2020 16:02:00 -0000 In-Reply-To: <20200221153958.GP3888@redhat.com> (Richard W. M. Jones's message of "Fri, 21 Feb 2020 15:39:58 +0000") Message-ID: <87mu9cc4jf.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00027.txt.bz2 * Richard W. M. Jones: > On Fri, Feb 21, 2020 at 04:00:30PM +0100, Florian Weimer wrote: >> * Richard W. M. Jones: >>=20 >> > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote: >> >> I think what confuses me is that keep talking about a single binary, = but >> >> clearly there is this separate vddk DSO, and there is talk of plugins. >> >> So it seems to me that multiple files are involved already? >> > >> > nbdkit is a standalone binary that happens to be able to load plugins >> > from a well-known path, eg nbdkit-vddk-plugin.so. nbdkit knows the >> > path for plugins, and there's a wrapper allowing it to get local >> > plugins even when it's still in the build directory. Adding another >> > file would mean another path (or overloading the meaning of the plugin >> > path) and just makes the whole thing more fragile and complex. >> > >> > Having said all that, what would also solve this is either an API for >> > updating LD_LIBRARY_PATH after the program has started; or making >> > setenv ("LD_LIBRARY_PATH",...) DTRT*; or some kind of dlopen() variant >> > which takes a library path as an extra parameter. >>=20 >> Have you tried adding DT_RUNPATH or DT_RPATH to nbdkit-vddk-plugin.so? >> Or does the path have to be chosen dynamically? > > To be clear, the situation is: > > nbdkit (free) > -> dlopens nbdkit-vddk-plugin.so (free) > -> dlopens libvixDiskLib.so (proprietary) > -> dlopens other proprietary plugins > -> both libvixDiskLib.so and its plugins have DT_NEEDED > "libstdc++.so.X" and other objects that have odd/old > compiled versions in its own directory > > It's the proprietary library libvixDiskLib.so (colloquially known as "VDD= K") > which has trouble opening its own plugins. I guess you mean adding > DT_* to the proprietary library? No, to nbdkit-vddk-plugin.so. But it looks like have misunderstood the request. Do you want to inhibit loading the libstdc++.so.X from vddk, or the opposite=E2=80=94ensure that it is loaded? The latter obviously taints the process. But maybe that's what you want? Thanks, Florian