in reply to Perl 5.8.8 build on WinXP

The essential rule is:

If the .pm file lives in the path /yourperl/site/lib/your/module.pm

Then the associated .dll needs to be in /yourperl/site/lib/auto/your/module.dll


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: Perl 5.8.8 build on WinXP
by syphilis (Archbishop) on Sep 15, 2008 at 19:16 UTC
    Then the associated .dll needs to be in /yourperl/site/lib/auto/your/module.dll

    That's what I thought, too ... until I discovered recently that the dll can go in, for example, /yourperl/site/lib/module.dll. The 'auto' is not needed, and the 'your' is not needed either. I've just double checked this by relocating perl/site/5.10.0/lib/auto/Math/GMP/GMP.dll to perl/site/5.10.0/lib/GMP.dll. There may be other alternative locations, too. I haven't checked.

    Cheers,
    Rob

      True, but as this extract from Dynaloader.pm shows, it looks in site/lib/auto/module first:

      foreach (@INC) { chop($_ = VMS::Filespec::unixpath($_)) if $Is_VMS; my $dir; if ($Is_MacOS) { my $path = $_; if ($Mac_FS && ! -d $path) { $path = Mac::FileSpec::Unixish::nativize($path); } $path .= ":" unless /:$/; $dir = "${path}auto:$modpname"; } else { $dir = "$_/auto/$modpname"; } next unless -d $dir; # skip over uninteresting directories # check for common cases to avoid autoload of dl_findfile my $try = $Is_MacOS ? "$dir:$modfname.$dl_dlext" : "$dir/$modfname +.$dl_dlext"; last if $file = ($do_expand) ? dl_expandspec($try) : ((-f $try) && + $try); # no luck here, save dir for possible later dl_findfile search push @dirs, $dir; }

      After that, it basically goes off on a mind-blowingly slow and complicated tour of every directory in @INC and a few other places. The question is: why? What does this 'flexibily' buy anyone? It's just more complexity for no gain.

      The danger of omitting the your is that Simple.dll from the XS version of XML::Simple overwrites Simple.dll from the XS version of CGI::Simple. Omitting the auto compounds the problem.

      Define a rule, document it and stick to it. And then, when the dll isn't found the module can report site/lib/auto/your/module.dll not found. Currently, they cannot do that because they would have to say:

      Couldn't find Module.dll in site/lib/auto/your, or site/lib/auto or si +te/lib or site/lib/some/other/module/You/Used or site/lib/some/Other/ +Random/Place/WeT/hought/To/Try/ ...

      Sigh! If only we could go back in time.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        What does this 'flexibily' buy anyone? It's just more complexity for no gain.

        Yes - it's just flexibility for the sake of flexibility. All it can ever "buy" is more headaches - and they're easily picked up for free, anyway.

        Math::GSL actually does this, btw - which is how I came to notice it. Since Math::GSL contains nearly 50 modules, I have nearly 50 dll's (all from Math::GSL) in perl/site/lib. For perl/site/lib/Math/GSL/Vector.pm, I have perl/site/lib/Vector.dll, etc. As you've noted, that's ok .... so long as no other module (eg Bit::Vector) decides to do the same thing.

        I'll write a patch and send it to the Math::GSL authors. It's messy having nearly 50 dll's in perl/site/lib alongside various pm and pod files.

        Cheers,
        Rob