On Thu, 5 Jun 2025 at 13:03, Reuben Thomas <[email protected]> wrote: > On Mon, 5 May 2025 at 12:51, Reuben Thomas <[email protected]> wrote: > >> On Fri, 2 May 2025 at 02:30, Bruno Haible <[email protected]> wrote: >> >> I don't think requiring -ldl is a "small" price to pay. It increases the >>> startup times of the programs linked to that library. Therefore how about >>> using dladdr only on those platforms where it is in libc? This would >>> cover >>> all the platform that you mentioned, and on Cygwin it would be a speedup >>> (likely no system calls instead of reading from the /proc file system). >>> >> >> I just re-read this, and realised that presumably this means that using >> dladdr would also be an improvement on Linux with glibc or uClibc, where >> currently we also read /proc? Which means that the /proc-reading code can >> be removed, as it is only used on the above-mentioned combinations plus >> Cygwin, which you already said would be faster with dladdr. >> >> I attach an updated patch. I have dealt with the shortcomings I >> previously identified: I check whether the path returned by dladdr is NULL >> before attempting to strdup it, and I add the same support to the >> relocatable-lib module. I have removed the previous Cygwin/Linux code in >> favour of this simpler, faster method. >> > > Ping! Any further thoughts on this? I've made a release of Enchant using > this patch and so far no complaints… >
I'm still wondering if it's possible to upstream this patch, which simplifies the relocatable module (in particular removing quite a lot of Linux-specific code) while making it work well on more OSes (in particular macOS). The impetus to write this check is actually a complaint, but this is from developers using libenchant who don't like that I'm using a patched version of gnulib! -- Web: rrt.sc3d.org
