On Fri, 28 Nov 2025 at 00:18, Bruno Haible <[email protected]> wrote:

> Hi Reuben,
>
> This thread derailed into a dead end:
>
> 1) In https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00004.html
>    you proposed a patch supposed to fix a problem on macOS and *BSDs.
>
> 2) In https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00009.html
>    I replied that I don't want a dependency on libdl or libdld, and that
>    I would agree to use dladdr() only on those platforms where it is in
> libc:
>      musl, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, Cygwin, Minix.
>
> 3) In your reply you sent a modified patch that ignores my reply and
>    uses libdl, in particular, on Linux/glibc. This patch is not going
>    to be applied in Gnulib.
>

Thanks very much for getting back to me with a detailed summary of The
Story So Far.

I think I assumed the only problem you had with libdl was the slow-down in
startup time, which, as I pointed out, was more than compensated by the
speedup at run-time, because currently: 'find_shared_library_fullname costs
"ca. 0.3ms on Linux, 3 ms on Cygwin 1.5, and 5 ms on Cygwin 1.7"'.

Since you didn't reply to that point, I thought you accepted my argument.

So, I'll re-do the patch along the lines you ask for. Specifically, that
means using the /proc-reading code for Linux.

There's one other case that occurs to me: what about platforms where dladdr
is not in libc, but there is no other implementation of "costly
relocatable"? Specifically, on Hurd, Android, Haiku and HP-UX. Apart from
maybe Android, I presume the /proc-reading code won't work there, but it
would be good to offer the ENABLE_COSTLY_RELOCATABLE-gated functionality.

-- 
Web: rrt.sc3d.org

Reply via email to