Is it possible to write an XS module when the shared library is already mapped into the process space?

Question

This is on the limits of what I know, please correct any confusion here. In this question I ask why functionality provided by libm isn't already exposed to the user with a Perl interface. Now I want to know how it's done.

There is a module on CPAN that claims to do called Math::Libm. This works fine, but as a question on implementation when I use this I find that not just is libm mapped into the process as with any running Perl interpreter on Debian,

7f719246d000-7f719247c000 r--p 00000000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f719247c000-7f7192516000 r-xp 0000f000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f7192516000-7f71925af000 r--p 000a9000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f71925af000-7f71925b0000 r--p 00141000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so
7f71925b0000-7f71925b1000 rw-p 00142000 fe:01 86513750                   /usr/lib/x86_64-linux-gnu/libm-2.31.so

But Math::Libm also maps in another libm shared object,

7fb649043000-7fb649044000 r--p 00000000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb649044000-7fb649049000 r-xp 00001000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb649049000-7fb64904a000 r--p 00006000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb64904a000-7fb64904b000 r--p 00006000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so
7fb64904b000-7fb64904c000 rw-p 00007000 fe:01 11143927                   /home/ecarroll/perl5/lib/perl5/x86_64-linux-gnu-thread-multi/auto/Math/Libm/Libm.so

This seems to be because Autoloader loads the external shared object.

Is it possible to access the symbols already in the resident process without loading an external shared object?

Answer 1

Is it possible to access the symbols already in the resident process without loading an external shared object?

You need to^† load the XS Libm.so to access C library functions from Perl, but when Libm.so is loaded at runtime using dlopen() (see dl_load_file()) the dynamic loader will recognize that Libm.so requires libm.so but since libm.so has already been loaded by the dynamic linker (when running perl itself), it will not be reloaded but an existing filehandle will be returned, see this Q&A, so the shared library libm.so is not loaded twice.

Footnotes:

† : But see also C::DynaLib, and FFI::Platypus for alternatives that does not require XS