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
