RE: [NeoStats-Devel] Perl on Win32

"M" <[email protected]> Thu, 11 Aug 2005 23:46:18 +0100
Newsgroups gmane.comp.neostats.devel
Message-ID <[email protected]>
Justin Hammond wrote:
> Hi Mark,
> I've struggled through getting Perl working on Win32, and can 
> say "Success".
> Almost. :)

I thought you were still getting it running generally otherwise I would have
looked into it.

> Well, I lie, it works fine, but I'm not sure about the 
> linking phase. In the final linking phase, I had to link in 
> perl58.lib, when in fact we just want to load that 
> dynamically on startup (as a DLL). 

We have to link something due to the nature of DLLs. Usually there is an
export library that you link to which resolves the necessary symbols for
later DLL loading. For NeoStats modules I do not go through all the DLL
hoops but each module links against a neostats core export library for
compilation of the modules. For core calls into the module DLL, it has to
lookup the symbols as for a *nix dl. 

> I'm worried if we the 
> perl58.lib file in linked into NeoStats, then its going to be 
> very very version specific with regards to what version of 
> ActivePerl that is installed.

To use Perl as a DLL, we have to load it and resolve all functions we wish
to call. As such, we are still likely to run into version issues if a
function changes in parameters or operation between versions. Since we are
unable to resolve versioning issues with *nix libraries used from source
such as CURL, we are unlikely to achieve it on Win32 relying on binary
version compatibility.

The Perl build already fails to load, let alone run, if the perl58.dll file
is not found so it is using the DLL file somehow. This also occurs if the
LoadLibrary call is removed so the library must be handling it.

I assume we are allowed to redistribute the DLL file and since we can only
successfully load a DLL that matches the library we link against, I do not
see that this should be of a concern for binary distros. We just ship with
the DLL version we want to use. Source distros we can merely state which
version we wish to insist on but I expect we will have very few (if any)
Windows users building NeoStats from source so we are unlikely to run into
complaints about this. 

Windows does not support symbolic links, so we have to request perlxxx.dll
anyway since perl.dll could be anything including somethat that is not
actually Perl. Standard procedure for Windows is to distribute all run time
components rather than assuming the user will go on to install several other
systems which may or may not be compatible. It is much easier to have
perl58.dll in the install directory rather than relying on end users to set
it up. You can not assume that your average Windows user will already have a
version of Perl installed or has any desire to do so.

> To test it out, grab the latest (5.8.x) version of ActivePerl 
> and install it in c:\perl (or modify the includes and lib in 
> Perl-Debug configuration option for Visual Studio)

When trying, NeoStats cannot find perl58.dll when attempting to run. By
fudging it, NeoStats merely segfaults when trying to load a perl module. 

You appear to be trying to load the DLL and then immediately freeing it
which I suspect is not what you want to be doing, but removing this does not
resolve the segfault so I am assuming something is not initialised
somewhere. Being completely unfamiliar with the perl code, I have no idea
what to suggest is wrong. The segfault is on:

perl.c:load_perlmodule():PL_perl_destruct_level = 1;

Note, this is the first occurrence of this since it appears to be repeated
several times. It disassembles to something very unlike the C code so I
assume there is some macro magic happening here.


Mark.