RE: [NeoStats-Devel] Perl on Win32

> 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.
> 

All that's actually left is to implement the few remaining NeoStats API's
now. The actual embedding of Perl is complete, and  we have a pretty
"complete" support for perl modules now.


> > 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. 
> 

Ok, understood.

> > 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.
> 

Hrm, well, ActiveState do promise to maintain ABI between minor versions
though, so any perl58.dll should be ok (but I also realise we are working in
DLL hell here :))


> 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. 
> 

Hrm, the only problem here is that not only the DLL is required, but some
perl extensions and a lot of the Perl Modules (.pm files) so this could be
real tricky, but Depending on DNB's setup program he has, we might be able
to do some checks to see if perl is installed or not. I will go and try
moving perl around (ie, installation in another directory than where I
compiled from just to ensure we are not going to hit "runtime" issues with
perl installed in a different directory)

In case you didn't know, I've based the support around Xchats perl module as
well, which works natively under Win32, but in xchat, the perl modules is
supported via a DLL, which could result in the differences.


> 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.
> 

Hehe, yeah, and this was why I setup the perl build under a different config
in Visual Studio... Then we can have two releases, one with perl, one
without.

As for distributing Perlxxx.dll in NeoStats, I think we would have to go one
step further and "redistribute" the entire perl runtime. I'll go hunt and
see if there is a cut down version of the perl runtime as well.


> > 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. 

Well, I don't know how you isntalled Perl, does the standard perl.exe run
with no problems? As mentioned above, perl needs a lot of its support files
to operate, so this could be the problem if you "fudged" it. 

I used the MSI installation file from the activestate website. 

As far as the DLL load and unload, this was pretty much untouched from
Xchats version (minus a dialog box that pops up if it couldn't load). I'll
double check that I didn't fudge the load/unload logic there.


Being completely unfamiliar with the perl code, I 
> have no idea
> what to suggest is wrong.

Unless you are interested in brain tumors I suggest you keep it that way...
This was a lot harder than I thought as well. :)

 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.
> 

This global variable tells perl that when we destroy the perl interpreter
for that module, not to mess with the "global" space, but only the local
interpreter space, as we might have other perl modules still loaded. The
messages I seen on the web say we should be including it a few times during
the construct, because perl will default it back to 0, which is bad. 

Anyway, most of Perl's variables and functions are MACROs to the real
calls... I believe this is to support different threading options etc, which
I assume is not relevent for us correct?

Now what finally pisses me off is that it works for me, but not for you. Ok,
I'll go and do more research on this and get back to you shortly.

Thanks

Justin