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:
Jan Dubois
Date:
December 14, 2007 10:37
Subject:
RE: How to load a "loadable object" that has a non-default file extension ?
Message ID:
053c01c83e80$583c9340$08b5b9c0$@com
On Fri, 14 Dec 2007, Sisyphus wrote:

Your subject line is somewhat misleading: you don't want to use
a different _extension_, you want to use a different library
_name_ (you want to use pgplotxs.dll instead of pgplot.dll,
but you are not asking for pgplot.xsdll).

> 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?)

It was part of change 23348:

  http://public.activestate.com/cgi-bin/perlbrowse/p/23348

The idea behind that change was to move all the platform dependent
checking from runtime to buildtime: since DynaLoader.pm is an
auto-generated file, there is no reason that the Win32 version
checks $^O for any other platform at runtime.

However, I think that interpolating $dl_dlext and $dl_so at buildtime
was a mistake; we should have retained the module variables and
interpolated them at runtime.

I'll make a patch for this once the 5.10 code freeze is over.
 
> 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.

Renaming one of the libraries is certainly required in this case.  Another
way around the problem would be to build a statically linked pgplot.lib.
This also makes it easier for people using Par/PerlApp/Perl2Exe to
package applications using the module.

Cheers,
-Jan



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