----- Original Message -----
From: "Sisyphus" <[email protected]>
> I'm actually not sure that there *is* a fix to
> the primitive.t failure (short of using the SDK 2003 compiler).
I'm now quite sure that there *isn't* a fix from within the PDL source.
With ActivePerl, a call to srand() will seed the msvcrt.dll prg (since
ActivePerl uses the msvcrt.dll runtime).
But if PDL has been compiled on ActivePerl with VC 2008, then the
PDL::random() and PDL::grandom() functions will use the msvcr90.dll prg
(since VC 2008 uses the msvcr90.dll runtime). And the msvcr90.dll has seen
*no* srand() calls - remember, those srand() calls were seen only by the
msvcrt.dll. As far as the msvcr90.dll prg is concerned, srand() has not been
called at all, and it behaves accordingly.
I actually confirmed this with the following Inline::C script:
####################################
use warnings;
use strict;
use Inline C => <<'EOC';
void foo() {
printf("%d\n", rand());
}
EOC
srand 5;
foo();
srand 5;
foo();
####################################
If that script is run on ActivePerl using the same compiler (VC6) that was
used to build ActivePerl, then that script outputs the same number (54) both
times foo() is called.
But if I use either VC 2008 or VC 7 as the compiler (still using the same
build of ActivePerl), then the output is as if srand() has not been called
at all.
And if I use VC 7 as the compiler, and a perl built using that compiler (in
which case both the compiler and perl are using the msvcr70.dll runtime),
then I get 54 printed out twice, as expected and desired.
I don't see any way to resolve this - other than to have both perl and the
compiler using the same runtime ... which is just another way of saying that
the compiler in use needs to be the compiler that built perl.
Cheers,
Rob
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
