FAQ
I'm finding code like this all over MakeMaker.

# Some systems have restrictions on files names for DLL's etc.
# mod2fname returns appropriate file base name (typically truncated)
# It may also edit @modparts if required.
if (defined &DynaLoader::mod2fname) {
$modfname = &DynaLoader::mod2fname(\@modparts);
}

Ok...

What is DynaLoader::mod2fname?

Why isn't it documented?

Why is it in DynaLoader?

Why is it written in XS?

Why is it only defined in os2/os2.c and vms/vms.c?

Why isn't there a default version so we don't have to play this "is
mod2fname defined" guessing game?

Why do lots of things naughtily use it without bothering to load
DynaLoader? (I think this stems back to something about miniperl
maybe not having DynaLoader available, plus some microoptimization
concerns about not wanting to load DynaLoader.pm)


Some of those are somewhat rhetorical.


Since DynaLoader::mod2fname is only used in MakeMaker, and I can't see
any particular reason why it has to be in XS or DynaLoader. I'd
*strongly* urge they be purged and replaced with boring Perl methods
in MM_OS2 and MM_VMS with a dumb default in MM_Unix.


Dan, Ilya? Looks like you're the original authors. Can you think of
any reason why that would go wrong? And could you write me Perl
versions? Otherwise I'll have to try to convert the C functions into
Perl myself and nobody wants to see that happen. :) (I think I can
figure it out...)


--

Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
Commence simultaneous panic on my mark.

Search Discussions

  • Dan Sugalski at Feb 17, 2002 at 4:20 am

    At 2:20 AM -0500 2/16/02, Michael G Schwern wrote:
    I'm finding code like this all over MakeMaker.

    # Some systems have restrictions on files names for DLL's etc.
    # mod2fname returns appropriate file base name (typically truncated)
    # It may also edit @modparts if required.
    if (defined &DynaLoader::mod2fname) {
    $modfname = &DynaLoader::mod2fname(\@modparts);
    }

    Ok...

    What is DynaLoader::mod2fname?
    Turns a module name into a filename for the dynaloaded extension.
    Why isn't it documented?
    Beats me. I found it by accident.
    Why is it in DynaLoader?
    Because it produces the name that dynaloader ultimately uses to
    choose the file to dlopen.
    Why is it written in XS?
    Just, ummmm... because?
    Why is it only defined in os2/os2.c and vms/vms.c?
    It's in vms/vms.c because I needed it, and there were already some
    routines defined in there. Besides, this way it's there on startup on
    VMS without needing any modules loaded or anything.
    Why isn't there a default version so we don't have to play this "is
    mod2fname defined" guessing game?
    I think because originally it was only needed in the OS/2 build. I
    did it for VMS because I needed the functionality, and hte wedges
    were still there.
    Why do lots of things naughtily use it without bothering to load
    DynaLoader? (I think this stems back to something about miniperl
    maybe not having DynaLoader available, plus some microoptimization
    concerns about not wanting to load DynaLoader.pm)
    Got me. Ask Ilya.
    Since DynaLoader::mod2fname is only used in MakeMaker, and I can't see
    any particular reason why it has to be in XS or DynaLoader. I'd
    *strongly* urge they be purged and replaced with boring Perl methods
    in MM_OS2 and MM_VMS with a dumb default in MM_Unix.
    It's not only used in MakeMaker, though. DynaLoader uses it as well.

    I can't speak for OS/2, but on VMS it works like this.

    When we load in a shared library, the filename (not directory,
    device, or extension) is ultimately important. If I've loaded in,
    say, IO.EXE, then any later attempts to load in another file named
    IO.EXE will just use the IO.EXE we've already loaded. Even if the
    second IO.EXE is really [.TK]IO.EXE, VMS' image activator doesn't
    care--IO.EXE is IO.EXE. The rest is just useful in locating the file,
    it isn't considered part of the filename.

    What's worse, the image activator will check the logical tables
    first--if I've got a logical IO, it won't even try loading in IO.EXE.
    Instead it assumes that the logical IO points to the file we want to
    load, even when it doesn't.

    I expect you can picture the problem. (This isn't an issue with
    programs designed for VMS but, then, perl wasn't)

    The mod2fname routine on VMS turns colons into underscores and
    prepends a PL_, so the XS library for Tk::IO is named PL_TK__IO.EXE,
    which is definitely different from plain IO's PL_IO.EXE. Both
    MakeMaker and DynaLoader need this info--makemaker to name the
    extension during the build, and dynaloder to find the right file to
    load up.

    The ultimate impetus to get this going was the mod_perl port on VMS.
    There's an XS module Apache, but the server had an APACHE logical
    defined, so mod_perl would always fail on startup. Darned annoying.
    Dan, Ilya? Looks like you're the original authors. Can you think of
    any reason why that would go wrong? And could you write me Perl
    versions? Otherwise I'll have to try to convert the C functions into
    Perl myself and nobody wants to see that happen. :) (I think I can
    figure it out...)
    Don't, please--leave it as C, at least for VMS. That way it's always
    installed on startup.
    --
    Dan

    --------------------------------------"it's like this"-------------------
    Dan Sugalski even samurai
    dan@sidhe.org have teddy bears and even
    teddy bears get drunk
  • Michael G Schwern at Feb 17, 2002 at 4:32 am
    On Sat, Feb 16, 2002 at 11:20:11PM -0500, Dan Sugalski wrote:
    <The Horror snipped>
    Dan, Ilya? Looks like you're the original authors. Can you think of
    any reason why that would go wrong? And could you write me Perl
    versions? Otherwise I'll have to try to convert the C functions into
    Perl myself and nobody wants to see that happen. :) (I think I can
    figure it out...)
    Don't, please--leave it as C, at least for VMS. That way it's always
    installed on startup.
    You've got me convinced, I'll leave that all be.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    You see, in this world there's two kinds of people. Those with loaded
    guns, and those who dig. Dig.
    -- Blondie, "The Good, The Bad And The Ugly"

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedFeb 16, '02 at 8:04p
activeFeb 17, '02 at 4:32a
posts3
users2
websiteperl.org

2 users in discussion

Michael G Schwern: 2 posts Dan Sugalski: 1 post

People

Translate

site design / logo © 2022 Grokbase