On Mon, 6 Oct 2003, Steve Hay wrote: > Hi, > > 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'
Hi Steve, This error is from an incompatibility with LARGEFILES support - on about line 1966 of Apache.xs, there's a statcache = r->finfo which is trying to relate two different things with LARGEFILES support on Win32. This is fixed in the cvs. > 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? It's something that should be fixed ... It sounds like there's something askew in src\modules\win32\mod_perl.dsp; could you send me (privately) this file, and also src\modules\win32\mod_perl.dsp.orig? Thanks. -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
