RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
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
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Jan Dubois wrote: On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: The obvious question is; what are your include libraries for that module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to build with VC 6? That Platform SDK headers (in case the module uses APIs that were introduced with Win2K or later), followed by the VC6 ones for traditional CRT stuff. Bingo! Ok, so we are clear, we are still building to VC6. I just wanted to clarify that this isn't mixing and matching to MSVCRxx headers from a later compiler. In theory that might even be possible, but it's only fair to point out that it's becoming impossible to download VC6 or obtain the SDK flavor which will actually compile under it. Or are you compiling with a more modern VC against the older VC6 headers? (The issue with obtaining them remains). I don't see how Windows 9X/NT compatibility plays a role here. E.g. for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is Windows 2000, but the code is still using MSVCRT.dll for the various reasons I listed. Right - understood. That being said, we don't go out of our way to *break* Win9X compatibility, but we don't test on it, and won't try to fix anything unless it is obvious/trivial. :) Ditto, although I'm less vigorous about providing dynaload thunks now, unless a 2008/Vista or 2003/XP API would break on 2000. I'm interested in the potential performance advantage though. Did you do any measurements? I've only heard anecdotal evidence of a 5% improvement that leaves me quite unimpressed (for things like PerlBench a 5% difference is almost at the noise level). Right; we have entirely different designs on performance. For httpd, 5% would be a godsend :) I'll be collecting and reporting on such in the near future. The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. Yup - it's almost always the same story; some API returns memory that it expects the caller to free(), rather than a corresponding API release call. There are a host of such examples in the way that mod_perl was implemented. Even some of the API's (as I hint about the SSL modules) which are implemented as xs's that behave similarly. 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. Right; we aren't talking about optimizing, but simply interop. It used to work in earlier Perl 5.8.x versions too, but later releases of the 64-bit VC compiler in the Platform SDK broke things. I thought I fixed this ages ago, but I guess I only submitted the necessary patches earlier this year and they had not been included in any official P5P release: http://public.activestate.com/cgi-bin/perlbrowse/p/30878 However, there have been 64-bit ActivePerl releases of 5.8.8 on Windows since August 2006. :) Just FYI, all the 64-bit ActivePerl on Windows releases have been built with the VC version from the Windows Server 2003 SP1 SDK. That compiler is a special version of the VS2003 compiler that links against the 64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in a special bufferoverflowU.lib library if you use the /GS compiler option because MSVCRT.dll doesn't include the runtime support for the buffer overrun detection. Interesting detail, thanks. I had presumed as much (or that you had built it against an earlier DDK before they incorporated this fully into the SDK). I may have missed these, as I only skim the mod_perl mailing lists. I always assumes that you would either use the Newx()/Safefree() mechanism from Perl, or a corresponding mechanism from APR to manage your memory. Mixing them can be dangerous even with a single clib because the Perl mechanism may use memory before and after the allocated block to detect buffer overruns in testing builds etc. Right - of course should-be and are-actually are two different things :) And it's only fair to point out this isn't win32 specific, libs linked against an optimized allocator on various flavors of unix will blow up in similar ways when the consuming app is linked to the 'stock' allocator. I sure hope that the problems can be solved by proper encapsulation of the different components. Re-releasing all components in sync whenever Microsoft releases a new compiler sounds lik
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, Jan Dubois wrote: On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: [ ... ] My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. 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. 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. -- best regards, Randy
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: > Jan Dubois wrote: >> I still haven't seen a compelling argument why someone wants to move >> away from using MSVCRT.dll (and then continue switching CRTs then >> every other year). > > The obvious question is; what are your include libraries for that > module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or > continue to build with VC 6? That Platform SDK headers (in case the module uses APIs that were introduced with Win2K or later), followed by the VC6 ones for traditional CRT stuff. > I'm concerned about drift; I understand the advantages to msvcrt.dll, > but fail to see where the proper headers are derived from, and agree > with some other posters that the performance advantage to moving to a > more modern compiler will outweigh the desire to remain "windows 9x" > compatible. I don't see how Windows 9X/NT compatibility plays a role here. E.g. for ActivePerl 5.10.0.10xx the minimum *supported* Windows version is Windows 2000, but the code is still using MSVCRT.dll for the various reasons I listed. That being said, we don't go out of our way to *break* Win9X compatibility, but we don't test on it, and won't try to fix anything unless it is obvious/trivial. I'm interested in the potential performance advantage though. Did you do any measurements? I've only heard anecdotal evidence of a 5% improvement that leaves me quite unimpressed (for things like PerlBench a 5% difference is almost at the noise level). >>> My instinct, with 2008 adding the new SDK features for apr such as >>> multicast group filtering, and the continued availability of a 2008 >>> 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries >>> for apache httpd to this 2008 release. Yes, probably retain either >>> .dsp files, or a makefile structure which allows folks to build to >>> anything from VC6 to a 'plain SDK' (it now includes the compilers >>> and tools), but for binaries, this will become foobar for folks who >>> use ActiveState. >> >> Why? What problems are going to happen? > > The major class of problems happens that there is one posix files > table per linked clib, one memory pool per linked clib, etc. When > resources cross from one to the next, that's the crux of the issue. Sure, but how do resources cross? Isn't this always a module bug to start with? Note that I have virtually no experience with the particular issues you may see with Perl inside Apache, but I've worked on many Perl embedding scenarios, putting Perl into COM controls, Windows services and .NET applications, so I'm well aware of the general issues, and how to solve them/work around them. 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. >> This is not correct. All the 64-bit support code is already in Perl >> 5.8.x as well. > > Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our > favorite perlmongers to put their full attention to 5.10 first (good > choice IMHO). It used to work in earlier Perl 5.8.x versions too, but later releases of the 64-bit VC compiler in the Platform SDK broke things. I thought I fixed this ages ago, but I guess I only submitted the necessary patches earlier this year and they had not been included in any official P5P release: http://public.activestate.com/cgi-bin/perlbrowse/p/30878 However, there have been 64-bit ActivePerl releases of 5.8.8 on Windows since August 2006. Just FYI, all the 64-bit ActivePerl on Windows releases have been built with the VC version from the Windows Server 2003 SP1 SDK. That compiler is a special version of the VS2003 compiler that links against the 64-bit MSVCRT.dll instead of the MSVCR71.dll. You need to link in a special bufferoverflowU.lib library if you use the /GS compiler option because MSVCRT.dll doesn't include the runtime support for the buffer overrun detection. > Certainly some folks who are actively using it already will chime in, > I'm looking forward to their specific examples - it's why I brought > this up on modperl's list. Yes, please speak up; I'm very interested to hear about it. > I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of > any new box I personally use until and if I get around to building > perl and python myself), but point out that the glue in malloc/free, > faux-posix entities etc that have to span httpd to apr to modperl to > perl do have issues today that have been reported on-list. I may have missed these, as I only skim the mod_perl mailing lists. I always assumes that you would either use the Newx()/Safefree() mechanism from Perl, or a corresponding mechanism from APR to manage your memory. Mixing them can be dangerous even with a single clib because the Perl mechanism may use memory before and after the allocated block to detect buf
Re: mod_perl, ENV{'TZ'}, and localtime
Kirk Noda wrote:
> The thread seemed to die off. Still, is there a way to use $ENV{TZ} to
> modify the behavior of localtime?
The reason this does not work under modperl version 2.0 is because under
handler "perl-script", %ENV is untied from the C environment. The
localtime() function is implemented in C, and as a result, it will never
see the changes you made to $ENV{TZ} from mod_perl.
The way I got around this was to use Env::C, and override
CORE::localtime() with something like:
package MyLocaltime;
use Env::C;
sub import {
my $class = shift;
$class->export('CORE::GLOBAL', 'localtime');
}
sub localtime {
my $time = shift;
$time = time unless defined $time;
my $orig_tz = Env::C::getenv('TZ');
Env::C::setenv('TZ', $ENV{TZ}, 1);
my @ret = CORE::localtime($time);
Env::C::setenv('TZ', $orig_tz, 1);
return @ret;
}
The real problem is that this is only safe under a prefork MPM because
it is not thread safe. There really ought to be an option (IMO) where
you can make the untie of %ENV under perl-script to be optional. Maybe
something like PerlOptions +NoUntieEnv or something so that if you are
running under a prefork MPM, you do not need to resort to tactics like
the above.
Regards,
Michael Schout
Re: Visual Studio 2008 and ActiveState Perl 5.10 updates
Jan Dubois wrote: The initial switch away from MSVCRT.dll was due to a conflict inside Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become so important to the operation of Windows itself that the compiler team was no longer allowed to update it; ownership had been transferred to the OS team and the only update vehicle was Windows Update. This made it impossible to include updated versions of MSVCRT.dll with Visual Studio releases, and the compiler team went back to versioned runtime libraries. A very interesting perspective, thanks! I still haven't seen a compelling argument why someone wants to move away from using MSVCRT.dll (and then continue switching CRTs then every other year). The obvious question is; what are your include libraries for that module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or continue to build with VC 6? I'm concerned about drift; I understand the advantages to msvcrt.dll, but fail to see where the proper headers are derived from, and agree with some other posters that the performance advantage to moving to a more modern compiler will outweigh the desire to remain "windows 9x" compatible. One aspect of my current vc perspective is that really NT 4.0 and 9x are now "dead", as in "harmful when installed in the network cloud". So with the loss of further security fixes to the NT4/9x class OS's, I'm moving away from their support whatsoever for httpd 2.4 (3.0?) binaries. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. I tried back in the VS.NET days to compile with VC7 and link against MSVCRT.dll. It turned out to fail in some cases when compiler generated code (under C++) called help functions not present in MSVCRT.dll. I'd expect that... but I'm more concerned about insidious failures which aren't clean compile/link time exceptions. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Why? What problems are going to happen? The major class of problems happens that there is one posix files table per linked clib, one memory pool per linked clib, etc. When resources cross from one to the next, that's the crux of the issue. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. This is not correct. All the 64-bit support code is already in Perl 5.8.x as well. Ack, 5.8.9 IIUC, but AFAIK the 5.8.9 release was held up by our favorite perlmongers to put their full attention to 5.10 first (good choice IMHO). I have no idea what you are trying to get at here, and where your fatalistic attitude comes from. If there is a real problem using ActivePerl with mod_perl, then please let me know about it. I'm sure we can work it out. :) Certainly some folks who are actively using it already will chime in, I'm looking forward to their specific examples - it's why I brought this up on modperl's list. I'm not meaning to badmouth AS (to the contrary, it's my bootstrap of any new box I personally use until and if I get around to building perl and python myself), but point out that the glue in malloc/free, faux-posix entities etc that have to span httpd to apr to modperl to perl do have issues today that have been reported on-list. I suspect a good number of these will, ultimately, be resolved with a consistent clib across all components. Alternate solution is for each component to manage it's own resources and abstract them for the consumer; we are getting there, slowly. The breadth of cpan packages doesn't make this easier ;-) For example, OpenSSL needs to be built for both a host of perl ssl packages and for httpd mod_ssl (and apr-util, in the near future). Which build? One compiled on VC 9 or VC 6? Bill
RE: Visual Studio 2008 and ActiveState Perl 5.10 updates
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote: > Studio 2008, true to form, proves that MS is incapable of keeping > around a stdc library any longer than one product cycle. Yes, our long > awaited (not) MSVCR90 is here. You can expect a new runtime library version for each compiler release from Microsoft. This started back with VS.NET (MSVCR70), VS2003 (MSVCR71), VS2005 (MSVCR80) and now VS2008 (MSVCR90). The initial switch away from MSVCRT.dll was due to a conflict inside Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become so important to the operation of Windows itself that the compiler team was no longer allowed to update it; ownership had been transferred to the OS team and the only update vehicle was Windows Update. This made it impossible to include updated versions of MSVCRT.dll with Visual Studio releases, and the compiler team went back to versioned runtime libraries. > Just to put it in perspective, cross-library malloc/free, stdio and > some other facilities are tightly integrated into the clib, such that > compiling the application under one flavor, and using a library of > another which modifies the application's memory/stdio allocations > causes no end of troubles. This is not really true for Perl, which abstracts all runtime library dependencies away. As long as you include the Perl headers in your module code, you will use the same runtime library as Perl itself. > You might be also curious if AS is making progress at coming to a new > baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 > for python. Unfortunately, this version is also built under msvcrt. This was a conscious decision: Using MSVCRT.dll as the runtime library has many advantages: the library is already installed on *all* Windows systems, so you never need to distribute it yourself. This is important for tools like PAR, PerlApp and Perl2Exe that create selfcontained executables of Perl applications. Using MSVCRT.dll also allows to use both VC++6 and GCC from MinGW without loading duplicate runtimes. I still haven't seen a compelling argument why someone wants to move away from using MSVCRT.dll (and then continue switching CRTs then every other year). > The obvious question, why not compile apache and perl under vc 8 or 9 > but link to msvcrt.dll? The trouble which comes in here is that their > std headers correspond to msvcr90, not to msvcrt. As that library > evolves, it's going to inevitably drift from the msvcrt.lib. I tried back in the VS.NET days to compile with VC7 and link against MSVCRT.dll. It turned out to fail in some cases when compiler generated code (under C++) called help functions not present in MSVCRT.dll. > My instinct, with 2008 adding the new SDK features for apr such as > multicast group filtering, and the continued availability of a 2008 > 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries > for apache httpd to this 2008 release. Yes, probably retain either > .dsp files, or a makefile structure which allows folks to build to > anything from VC6 to a 'plain SDK' (it now includes the compilers and > tools), but for binaries, this will become foobar for folks who use > ActiveState. Why? What problems are going to happen? > Perl 5.10 is interesting for it's attention to Win32 64P model builds > (64ILP reflects an OS which represents int, long, pointer as 64 bits, > so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). > Because 64P is unusual in the family of 64 bit OS's, it's received the > least attention of all of the platforms. Perl 5.10 is purported to > catch win32 up significantly to the tried-and-true linux, solaris, bsd > 64 bit flavors. This is not correct. All the 64-bit support code is already in Perl 5.8.x as well. > So I'm posting this mostly for feedback to the rational of moving to a > compiler that will generate reliable 32 *and* 64 bit builds of httpd, > will be freely available (the point of the ASF is the source, and that > users can do something with it), and that decision will be locked at > the 2.4 release based on our strong commitment to binary > compatibility. > > It's very true that modules compiled for another runtime can coexist > very happily when the module does not free allocations from another > component, don't attempt to share faux-posix stdio resources, etc. > mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it > lives very happily in a VC6 build of httpd. But the way that perl, > mod_perl and httpd interact is not that trivial, and highly prone to > this class of problems. So I figure if there's a plan here, it will > likely satisfy the 80/20. > > If AS Perl can't part of that solution, so be it. I have no idea what you are trying to get at here, and where your fatalistic attitude comes from. If there is a real problem using ActivePerl with mod_perl, then please let me know about it. I'm sure we can work it out. :) Cheers, -Jan
Re: Can't use Crypt::RSA
try using Crypt::OpenSSL::RSA its a little faster. there is a memory leak in it, but the max- requests directive will make it pretty inconsequential. On Dec 28, 2007, at 5:37 AM, arnab wrote: Hi Everyone, I'm using a small script to use the Crypt::RSA module under windows using Active Perl v5.8.8 but it is showing Perl Command Line Interpreter has encountered a problem and needs to close... My script # #!/usr/bin/perl use strict; use warnings; use Crypt::RSA; # Use my to declare variables my ($crypted, $data, $plain, $private, $public, $rsa); # Set the data that will be encrypted $data = "hello"; # Create a new RSA object $rsa = new Crypt::RSA or die "Unable to create RSA object!\r\n"; # Generate a public private key pair ($public, $private) = $rsa->keygen(Size => 1024) or die "Unable to create key pair!\r\n"; undef($rsa); Could any body please suggest what may be the parameter for the function call $rsa->keygen( Thanks in advance. Arnab -- View this message in context: http://www.nabble.com/Can%27t-use- Crypt%3A%3ARSA-tp14524284p14524284.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Correct way to send http status code 206 -Partial content?
Hi,
What is the correct way to send http status code of 206 from from Modperl
Registry script [In modperl2/apache2]? I searched the modperl site but did
not find any examples.
I looked at the following redirect example [by setting
$r->status(Apache2::Const::HTTP_PARTIAL_CONTENT) and returning
Apache2::Const::HTTP_PARTIAL_CONTENT.]
This gives a http status code of 200 and internal error message in the
server.
http://perl.apache.org/docs/2.0/user/coding/cooking.html#Sending_Cookies_in_REDIRECT_Response__ModPerl__Registry_
OK, after a while, I also tried setting $r->statusline( ) and this seems to
work, but I am not sure if this the right way. I am pasting a sample code
that works correctly
Thanx,
HB.
Sample code that works fine
use Apache2::Request;
use Apache2::RequestUtil;
use Data::Dumper;
use Apache2::Const -compile => qw(HTTP_PARTIAL_CONTENT OK HTTP_OK);
use APR::Table ();
use strict;
use constant MOD_PERL => $ENV{MOD_PERL};
my $r = shift;
$r->headers_out->set('Accept-Ranges'=> 'bytes');
$r->content_type('audio/mpeg');
$r->headers_out->set('Content-Length' => 2);
$r->headers_out->set('Content-Range' => 'bytes 0-1/4');
$r->status_line(Apache2::Const::HTTP_PARTIAL_CONTENT. ' Partial
Content' );
$r->print('ZZ');
return Apache2::Const::OK;
mod_perl, ENV{'TZ'}, and localtime
Hello,
I'd like to reference the Tues 03 Oct '06 thread with subject:
RE: Using ENV{'TZ'} in mod_perl
http://mail-archives.apache.org/mod_mbox/perl-modperl/200610.mbox/browser
The thread seemed to die off. Still, is there a way to use $ENV{TZ}
to modify the behavior of localtime? I get the same result on
mod_perl 1.99_16 and 2.0.3. PerlTaintCheck is off for
both. POSIX::tzset() does not correct the mis(?)behavior. I'd like
to get this to work with the apache 2.0.52 + mod_perl 1.99_16 setup.
BTW, This did work way back on apache 1.3.27 + mod_perl 1.27.
###
### Test script
###
#!/usr/bin/perl
use strict;
use warnings;
use POSIX qw(tzset tzname);
print "Content-type: text/plain\n\n";
$ENV{'TZ'} = 'US/Eastern';
POSIX::tzset();
my $eastern = localtime();
my ($estd, $edst) = POSIX::tzname();
foreach my $tmp (sort keys %ENV) {
printf("%-30s:%s\n",$tmp,$ENV{$tmp});
}
print "\n";
$ENV{'TZ'} = 'US/Pacific';
POSIX::tzset();
my $pacific = localtime();
my ($pstd, $pdst) = POSIX::tzname();
print
"Eastern: $eastern\n",
"Eastern: std: $estd dst: $edst\n",
"Pacific: $pacific\n",
"Pacific: std: $pstd dst: $pdst\n",
;
###
### Test 1 (fails)
###
GATEWAY_INTERFACE :CGI/1.1
MOD_PERL :mod_perl/2.0.3
MOD_PERL_API_VERSION :2
SERVER_SOFTWARE :Apache/2.2.6 (Fedora)
Eastern: Fri Dec 28 11:59:31 2007
Eastern: std: PST dst: PDT
Pacific: Fri Dec 28 11:59:31 2007
Pacific: std: PST dst: PDT
###
### Test 2 (fails)
###
GATEWAY_INTERFACE :CGI/1.1
MOD_PERL :mod_perl/1.99_16
SERVER_SOFTWARE :Apache/2.0.52 (Red Hat)
Eastern: Fri Dec 28 12:04:04 2007
Eastern: std: PST dst: PDT
Pacific: Fri Dec 28 12:04:04 2007
Pacific: std: PST dst: PDT
###
### Test 3 (works, non mod_perl)
###
GATEWAY_INTERFACE :CGI/1.1
SERVER_SOFTWARE :Apache/2.2.6 (Fedora)
Eastern: Fri Dec 28 15:26:35 2007
Eastern: std: EST dst: EDT
Pacific: Fri Dec 28 12:26:35 2007
Pacific: std: PST dst: PDT
###
### Test 4 (works, really old mod_perl+apache)
###
GATEWAY_INTERFACE :CGI-Perl/1.1
MOD_PERL :mod_perl/1.27
SERVER_SOFTWARE :Apache/1.3.27 (Unix) mod_perl/1.27
AuthMySQL/2.20 PHP/4.2.3 mod_ssl/2.8.11 OpenSSL/0.9.6g
Eastern: Fri Dec 28 15:44:11 2007
Eastern: std: EST dst: EDT
Pacific: Fri Dec 28 12:44:12 2007
Pacific: std: PST dst: PDT
DBD::mysql library issue on mod_perl2/Leopard
Hi all, I'm having some trouble with DBD::mysql under mod_perl2 on Leopard. The build process when just fine, make test didn't show any errors and running it in console and as CGI didn't show any errors. I already tried adding "PerlSetEnv LD_LIBRARY_PATH '/usr/local/mysql/lib/mysql/:/usr/lib'" and "SetEnv LD_LIBRARY_PATH /usr/local/mysql/lib/mysql" to my configuration (which points to the libmysqlclient.15.dylib file) The error log includes these messages for every request sent: dyld: lazy symbol binding failed: Symbol not found: _mysql_server_init Referenced from: /Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Expected in: dynamic lookup dyld: Symbol not found: _mysql_server_init Referenced from: /Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Expected in: dynamic lookup [Sun Dec 09 23:16:22 2007] [notice] child pid 439 exit signal Trace/BPT trap (5) Any ideas? PS: I already tested this with the very latest DBD::mysql (4.006) and crossposted to the DBD::mysql mailing list a couple of weeks ago. -- Hendrik Van Belleghem Spine - The backbone for your website - http://spine.sf.net
Visual Studio 2008 and ActiveState Perl 5.10 updates
Well folks, here's the news... Studio 2008, true to form, proves that MS is incapable of keeping around a stdc library any longer than one product cycle. Yes, our long awaited (not) MSVCR90 is here. Just to put it in perspective, cross-library malloc/free, stdio and some other facilities are tightly integrated into the clib, such that compiling the application under one flavor, and using a library of another which modifies the application's memory/stdio allocations causes no end of troubles. You might be also curious if AS is making progress at coming to a new baseline msvcrt for perl, since they had adopted Studio 2003's msvcr71 for python. Unfortunately, this version is also built under msvcrt. The obvious question, why not compile apache and perl under vc 8 or 9 but link to msvcrt.dll? The trouble which comes in here is that their std headers correspond to msvcr90, not to msvcrt. As that library evolves, it's going to inevitably drift from the msvcrt.lib. My instinct, with 2008 adding the new SDK features for apr such as multicast group filtering, and the continued availability of a 2008 'express'/'lite' free version, is to take httpd 2.4 (3.0?) binaries for apache httpd to this 2008 release. Yes, probably retain either .dsp files, or a makefile structure which allows folks to build to anything from VC6 to a 'plain SDK' (it now includes the compilers and tools), but for binaries, this will become foobar for folks who use ActiveState. Perl 5.10 is interesting for it's attention to Win32 64P model builds (64ILP reflects an OS which represents int, long, pointer as 64 bits, so Win32's 64P model reflects a 32 bit int/long, and 64 bit pointer). Because 64P is unusual in the family of 64 bit OS's, it's received the least attention of all of the platforms. Perl 5.10 is purported to catch win32 up significantly to the tried-and-true linux, solaris, bsd 64 bit flavors. So I'm posting this mostly for feedback to the rational of moving to a compiler that will generate reliable 32 *and* 64 bit builds of httpd, will be freely available (the point of the ASF is the source, and that users can do something with it), and that decision will be locked at the 2.4 release based on our strong commitment to binary compatibility. It's very true that modules compiled for another runtime can coexist very happily when the module does not free allocations from another component, don't attempt to share faux-posix stdio resources, etc. mod_aspdotnet is a great example; compiled with VS.NET or VS2005 it lives very happily in a VC6 build of httpd. But the way that perl, mod_perl and httpd interact is not that trivial, and highly prone to this class of problems. So I figure if there's a plan here, it will likely satisfy the 80/20. If AS Perl can't part of that solution, so be it. Bill
Re: Can't use Crypt::RSA
On Fri, 28 Dec 2007, Michael Peters wrote: Btw, ActiveState seems pretty busted right now for a whole lot of things. http://use.perl.org/~Alias/journal/35219 Granted this is 5.10 (mod_perl itself doesn't quite work yet with 5.10) but AS 5.8 has similar problems, just not as many. For the benefit of ActivePerl users reading this, the problem raised in http://use.perl.org/~Alias/journal/35219 about not being able to upgrade core modules was addressed with ppm4: http://www.nabble.com/ANNOUNCE:-Beta-of-PPM-version-4-released-td4906225.html (click on "Show quoted text" to see the release notes), together with the adjustment of @INC to set C:\Perl\site\lib before C:\Perl\lib. See also the note at the top of http://ppm.activestate.com/BuildStatus/5.10-A.html for known issues regarding the state of ActiveState's 10xx ppm repository. -- best regards, Randy Kobes
Re: Can't use Crypt::RSA
arnab wrote: > Hi Everyone, > > I'm using a small script to use the Crypt::RSA module under windows using > Active Perl v5.8.8 but it is showing Perl Command Line Interpreter has > encountered a problem and needs to close... None of these things has anything to do with mod_perl. Try an Active State or Windows Perl mailing list instead. Btw, ActiveState seems pretty busted right now for a whole lot of things. http://use.perl.org/~Alias/journal/35219 Granted this is 5.10 (mod_perl itself doesn't quite work yet with 5.10) but AS 5.8 has similar problems, just not as many. -- Michael Peters Developer Plus Three, LP
Can't use Crypt::RSA
Hi Everyone, I'm using a small script to use the Crypt::RSA module under windows using Active Perl v5.8.8 but it is showing Perl Command Line Interpreter has encountered a problem and needs to close... My script # #!/usr/bin/perl use strict; use warnings; use Crypt::RSA; # Use my to declare variables my ($crypted, $data, $plain, $private, $public, $rsa); # Set the data that will be encrypted $data = "hello"; # Create a new RSA object $rsa = new Crypt::RSA or die "Unable to create RSA object!\r\n"; # Generate a public private key pair ($public, $private) = $rsa->keygen(Size => 1024) or die "Unable to create key pair!\r\n"; undef($rsa); Could any body please suggest what may be the parameter for the function call $rsa->keygen( Thanks in advance. Arnab -- View this message in context: http://www.nabble.com/Can%27t-use-Crypt%3A%3ARSA-tp14524284p14524284.html Sent from the mod_perl - General mailing list archive at Nabble.com.
