From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 29CB33839401; Mon, 6 Sep 2021 08:32:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29CB33839401 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/28248] is there a way to LD_PRELOAD library before other dynamic libraries? Date: Mon, 06 Sep 2021 08:32:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.33 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fweimer at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 08:32:49 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28248 Florian Weimer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer at redhat dot com --- Comment #3 from Florian Weimer --- (In reply to Milian Wolff from comment #2) > I see, thank you! >=20 > Is there an alternative mechanism - potentially low-level / undocumented - > that I could leverage to somehow inject my interposing library in such a > way, that it's initialization happens after libc, but before any other > libraries? For glibc 2.34 on Linux, linking with -Wl,-z,initfirst should work. glibc should no longer use DF_1_INITFIRST itself, so it's available for applicati= on use. > That way, I can call `__libc_freeres` safely, as no other library code ru= n - > except that of libc itself. So this is about destructors? glibc currently does not guarantee that destructors run in the opposite order of constructors (even without dlclose, which can make some reordering necessary due to early unloading). --=20 You are receiving this mail because: You are on the CC list for the bug.=