During the course of testing mp1.29-rc1 I ran into a strange problem, probably Windows-specific, which I've seen before but never got to the bottom of.
I have Apache 1.3.28 installed in C:\apache and Perl 5.8.1 in C:\perl5. The latter has all the paths in it's Config.pm pointing to C:\perl5 subdirs, and I have C:\perl5\bin on the PATH (and no other Perl directories on the PATH).
I then extract the mp1 source archive into C:\Temp and run:
perl Makefile.PL APACHE_SRC=C:/apache EAPI nmake nmake test
Normally this works fine, but occasionally I get errors from "nmake". Under mp1.28 I sometimes get this at the start of the "msdev" command run by "nmake":
Compiling... Apache.c Apache.xs(1966) : error C2115: '=' : incompatible types [...] Error executing cl.exe. mod_perl.so - 1 error(s), 1 warning(s) NMAKE : fatal error U1077: 'msdev' : return code '0x1'
while under mp1.29-rc1 I got this at the end of the "msdev" command:
Linking...
Creating library Release/mod_perl.lib and object Release/mod_perl.exp
perl_util.obj : error LNK2001: unresolved external symbol _Perl_croak_nocontext
[...]
Release/mod_perl.so : fatal error LNK1120: 42 unresolved externals
Error executing link.exe.
mod_perl.so - 180 error(s), 1 warning(s)
NMAKE : fatal error U1077: 'msdev' : return code '0xb4'
I've finally tracked down what triggers this behaviour (it's the same trigger in each case), but I can't explain why. If I have another Perl build installed in C:\perl then I get the above errors; if I haven't then I don't!
I suspect that problem is also related to the fact that the other Perl build that I sometimes have in C:\perl is a threaded Perl (a la ActivePerl) whereas the one in C:\perl5 is non-threaded, hence the error regarding "Perl_croak_nocontext" when the wrong Perl setup gets picked up. (Basically, I prefer the non-threaded Perl for my production work with mp1, but I also have a threaded Perl kicking around for mp2 testing.)
Presumably something from the C:\perl installation is being used (in preference to the C:\perl5 installation that should be being used) if it is present. Why does this happen? All I have to do is move C:\perl out of the way (say, to C:\perl.mp2) and it all works fine again.
Also, why is there a difference between 1.28 and 1.29-rc1 in the way in which it breaks? Is that related to this change in the ChangeLog?:
For Win32, keep drive letters in mod_perl.dsp to fix bug, reported by DH <[EMAIL PROTECTED]>, when compiling mod_perl in cases where Apache and Perl are on different drives [Randy Kobes].
It's not an urgent problem for me since I have a workaround, but mp's build process really shouldn't be picking up the "wrong" Perl. All the other CPAN modules I'm using (150+ !) build fine with the other Perl sitting in C:\perl, so why shouldn't mod_perl?
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
