Hi Reuben, > I just ran into the problem that this function does nothing on macOS. > Indeed, it only works on Linux with glibc or uClibc, and Cygwin. (There's > equivalent but separate code for native Windows, of course.) > > A little investigation suggests that macOS and other platforms could use > dladdr to get this information. This seems rather obvious, so is there any > reason this has not already been implemented? dladdr is not standardized, > of course, but it does seem to be implemented on FreeBSD, NetBSD and > OpenBSD. The only reason not to use it that I can think of is that it > requires -ldl, but that seems a fairly small price to pay on platforms that > don't have another solution. > > I tried it on macOS, and it worked as expected. > > I attach a proof of concept patch for current git master. > > Things I can think of that would need to be improved: check that the > returned path isn't NULL, add the same support to the relocatable-lib > module (I've just patched relocatable-lib-lgpl). But since it's so obvious, > I thought I'd check first that there isn't a fatal flaw!
Indeed, dladdr sounds like it might well work. It's even in POSIX:2024 [1]. According to gnulib's symbol database, dladdr is - in libc on musl, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, Cygwin, Minix, - in libdl on Linux/glibc, Hurd, Android, Haiku, - in libdld on HP-UX. 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). Bruno [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/dladdr.html
