perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Dubois" <j...@activestate.com>
Subject RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
Date Sat, 29 Dec 2007 07:30:13 GMT
On Fri, 28 Dec 2007, Randy Kobes wrote:
> On Fri, 28 Dec 2007, Jan Dubois wrote:
> > Therefore I'm genuinely interested to learn where the problems are
> > if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> > with VC7.  I would expect this to work just fine if we ignore the
> > address space wasted by essentially unused surplus clibs.
> 
> I'm not sure if this is a clean example, but there was
> a report:
>    http://marc.info/?l=apache-modperl&m=119140365320503&w=2
> where mod_perl and Apache (compiled with VC8) did not
> work with ActivePerl (VC6), whereas switching to a mod_perl
> compiled with VC6 with the same Apache and Perl
> did (seemingly) work.

I didn't find enough information in that thread to figure out what
the problem might be.  It could very well be a module issue and
not a problem with mod_perl itself.
 
> Also, Steve Hay reports that his Win32::SharedFileOpen
> module:
>   http://search.cpan.org/src/SHAY/Win32-SharedFileOpen-3.36/INSTALL
> and his Win32::UTCFileTime module:
>   http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL
> will only work with ActivePerl when they're compiled with VC6.

I've looked at both, and they indeed must be compiled using the same
runtime library as the corresponding perl5x.dll: Both modules use
core Perl APIs and either insert FILE* pointers received from the
CRT into Perl data structures, or try to turn a FILE* pointer from
Perl into a fileno using the CRT.

Both extensions contain code that should ideally be part of the core.
Or at least the core should provide the necessary thunks to access
the corresponding functions from its own CRT.

I wonder if there are many modules though that do this kind of diddling
with the PerlIO subsystem internals.

If there aren't, then I can see a few ways to resolve this:

* Maybe the functionality of these modules should be supported by
  the core.  I believe Steve already asked if the Win32::UTCFileTime
  code shouldn't be the default for Perl's handling of filetimes.

* Maybe we should add the required thunks to Perl.  E.g. add a
  Perl_get_osfhandle() function etc.

* Maybe add the modules to ActivePerl and/or the PPM repositories.
  (They should already be on the PPM server, but seem to be missing
  due to some buildbox meltdown).

Cheers,
-Jan



Mime
View raw message