develooper Front page | perl.perl5.porters | Postings from December 2007

Re: How to load a "loadable object" that has a non-default file extension ?

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
December 14, 2007 10:46
Subject:
Re: How to load a "loadable object" that has a non-default file extension ?
Message ID:
c9ab31fc0712141046p42d4556ewccf50cbb27f6466@mail.gmail.com
On Dec 14, 2007 11:52 AM, Sisyphus <sisyphus1@optusnet.com.au> wrote:
> Hi,
>
> (I'm not subscribed - please cc me.)
>
> On Win32, I can control the file extension that's given to the loadable
> object when building a module (extension).
>
> In the Makefile.PL it's just a matter of:
>
> ----------------------
> WriteMakefile (
>   .
>   .
>   DLEXT => 'my_ext',
>   .
>   .
> );
> ----------------------
>
> And then, if I'm building an extension called MYMOD, instead of getting a
> MYMOD.dll, I get a MYMOD.my_ext. (No problems to this stage - even on 5.10,
> the loadable object that's built is called MYMOD.my_ext.)
>
> To load the loadable object (and this is where the problem lies), it's then
> necessary to first let DynaLoader know that it needs to load MYMOD.my_ext
> instead of the more usual (default) MYMOD.dll.
> I've been doing this by overwriting $DynaLoader::dl_dlext in MYMOD.pm before
> calling bootstrap:
>
> ----------------------
> {
> local $DynaLoader::dl_dlext = 'my_ext';
> bootstrap MYMOD $VERSION;
> }
> ----------------------
>
> And that all works fine in perl 5.8 and perl 5.6.
>
> But in perl 5.10, DynaLoader croaks with "Can't locate loadable object for
> module MYMOD in @INC (@INC contains: .....". I suspect the value assigned to
> $DynaLoader::dl_dlext is not even being looked at - and DynaLoader is trying
> to load (the non-existent) MYMOD.dll .
> (Was this change to DynaLoader intentional?)
>
> By way of explanation - on Win32 we need to do something like this if we
> want to build, eg, the PGPLOT module against (the C library) pgplot.dll.
> Othwerwise Win32 seemingly fails to differentiate between the perl dll
> (PGPLOT.dll) and the C library dll (pgplot.dll) - and inevitably looks for
> "entry points" in the wrong dll, croaking when they're not found.
> If you look at the PGPLOT-2.20 source, you'll see that the Makefile.PL sets
> DLEXT to 'xs.dll' iff the OS is Win32 .... and in PGPLOT.pm
> $DynaLoader::dl_dlext is overwritten to 'xs.dll' iff the OS is Win32.
> No problems with 5.6 and 5.8 where it works fine - but what's the best way
> to get it working on 5.10 ?

A better solution than changing the file extension would be changing
the name of the loadable object so you would have, for example
PL_PGPLOT.dll or Perl_DLL_PGPLOT.dll (or similar) for the Perl
extension and avoid the namespace collision with pgplot.dll in the
registry (or wherever it is the collision is happening).  We've done
this on VMS for years.  You need to create a C<mod2fname> built-in
(see as an example what's in vms/vms.c), load it as
C<DynaLoader::mod2fname>, and the existing infrastructure in
DynaLoader should take care of the rest.

Any platform for which there is a single system-wide (or even
process-wide) namespace for loadable objects should definitely not be
creating Perl extensions without mangling the name in some way.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About