http://www.perlmonks.org?node_id=1209406

YenForYang has asked for the wisdom of the Perl Monks concerning the following question:

Recently I've been looking into what XSLoader and DynaLoader and I've been trying to figure out what they do behind the scenes so that maybe I can do (what they do) ("low-level") if I so wish (for whatever reason). It seems to me that XSLoader.pm just uses DynaLoader--it's a convenient module but using it to load XS seems like just an extra step. Well I've looked at DynaLoader as well, and I'm lost on how it does what it does. It implements functions like dl_load_file, dl_install_xsub, and dl_find_symbol but I can't seem to find any definitions. So I'm guessing they are defined in XS or something...but if the subroutines for loading XS are defined in XS, how does DynaLoader manage to do anything?

Replies are listed 'Best First'.
Re: Most direct way of loading XS?
by salva (Canon) on Feb 18, 2018 at 09:32 UTC
    but if the subroutines for loading XS are defined in XS, how does DynaLoader manage to do anything?

    DynaLoader XS code is compiled and linked statically into the perl executable.

Re: Most direct way of loading XS?
by Anonymous Monk on Feb 18, 2018 at 10:37 UTC
Re: Most direct way of loading XS?
by Anonymous Monk on Feb 18, 2018 at 14:36 UTC
    Also – it is a common layer to shield an operating-system specific implementation, thus helping to provide platform independence.

      Are you saying that hackers include C/XS code as a technique to keep Perl code platform independent?

      Update: I'm going to follow up since no reply has been forthcoming. There are a couple of Anonymous Monks who are legit hackers and my question was for potential clarification if I was missing something I might not understand. No follow up means I'm pretty sure I'm not missing anything and the upvotes the node above is attracting are irritating me.

      Including C code with your Perl code is close to the bottom of the list for effective methods of achieving platform independence as opposed to pure Perl which generally achieves it perfectly outside FS issues anyway. This non-answer, ALSO, HERE'S SOMETHING BARELY RELATED, NON-TECHNICAL, AND COINCIDENTALLY WRONG, screams sundialsvc4 to me despite the newfound self-control over formatting and logorrhea. You're going to continue to get the benefit of the doubt when posting without using your account. It absolutely does not make your wrong answers okay or expose bias—just general goodwill here—because you can trick a few visitors into the odd ++.

        I think you are misunderstanding the Anonymous Monk post.

        He doesn't say XS/C code is portable, but that it can be used to hide portability issues providing OS agnostic APIs to be used from Perl code.

        It is how the Perl core works. It deals with every OS quirk and custom, hidden them to the Perl programmer. And XS/C code can be used to do the same.

        Well, at least that is my reading.

        It absolutely does not make your wrong answers okay or expose bias—just general goodwill here—because you can trick a few visitors into the odd ++

        I don't feel that I was at all "tricked" when I gave AM a ++.

        But I certainly would not have ++'ed your post if I had known you would subsequently update it with such offensive garbage.

        Cheers,
        Rob