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.