This does not work because libm.so can be a linker script: handle = dlopen("libm.so", RTLD_LAZY); The proper way to do this is to include <gnu/lib-names.h> and use LIBM_SO.
Hi Florian, I'm reluctant code a glibc dependency into what I would like to be a fairly vanilla dlopen example. What if I used a function from libc itself (e.g., strlen()). Does the same issue exist? Cheers, Michael
(In reply to Michael Kerrisk from comment #1) > Hi Florian, > > I'm reluctant code a glibc dependency into what I would like to be a fairly > vanilla dlopen example. Fair point. Although the example might confuse users because even where it works, it typically needs development packages at run time (because the .so link are only installed by them). > What if I used a function from libc itself (e.g., > strlen()). Does the same issue exist? libc.so is a linker script, too. libm.so.6 and libc.so.6 are not, but they are glibc-specific to (some moderately current Solaris versions use libm.so.2 and libc.so.1, for example).
So, I'm inclined to close this as WONTFIX. I mean: this example will work for most people on most systems, right? The alternative is to create a bigger example where I build a little library that is then dlopen()-ed. But that seems like a little too much work, and might actually be less easy to understand than the current example. Do you have a strong objection to WONTFIX, Florian?
(In reply to Michael Kerrisk from comment #3) > So, I'm inclined to close this as WONTFIX. I mean: this example will work > for most people on most systems, right? With glibc, libm.so is increasingly a linker script on x86_64 due to this change: <https://sourceware.org/glibc/wiki/libmvec> This was introduced in glibc 2.22, so few distributions have this change yet.
Thanks for all of the info Florian. So, in the end it seems best to make the change you already suggested :-}. Done!