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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id E85E33971811 for ; Fri, 13 Nov 2020 21:41:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E85E33971811 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-272-pGEl6Lh7OUetwUDXAicnxw-1; Fri, 13 Nov 2020 16:41:36 -0500 X-MC-Unique: pGEl6Lh7OUetwUDXAicnxw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4B3B80734F; Fri, 13 Nov 2020 21:41:35 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-222.ams2.redhat.com [10.36.113.222]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A3F11002C04; Fri, 13 Nov 2020 21:41:34 +0000 (UTC) From: Florian Weimer To: Daniel Villeneuve via Libc-help Subject: Re: what is the dlopen criterion used to decide if library needs to be loaded? References: Date: Fri, 13 Nov 2020 22:41:33 +0100 In-Reply-To: (Daniel Villeneuve via Libc-help's message of "Fri, 13 Nov 2020 16:24:13 -0500") Message-ID: <878sb5rl2q.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 21:41:40 -0000 * Daniel Villeneuve via Libc-help: > By looking at the code in glibc, there seems to be a test using > inode/xdev, which does not rely on the name. > However, inodes can be reused immediately after unlink, so it seems > fragile to infer equality of contents just comparing inodes. The files are stilled mapped while the objects are still loaded, so they must exist unnamed in the the file system. Their content is also accessible via /proc/PID/map_files. I believe the inode/device pair is indeed unique under these circumstances. > In the end, I've rebuilt the library using the same name (not being > sure whether the inode would be the same or not), and before dlopen, I > create a hard link with a new unique name on the library and use that > as arg to dlopen (and then delete the hard link). > > Is this a safe way to ensure a newly built library is really loaded? It depends on what the soname of the library is. If you set it to a fixed value, the new library may be opened, but not loaded eventually because the soname is already known to the system. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill