perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: Problem building mp1 on Win32
Date Wed, 08 Oct 2003 03:00:10 GMT
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 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.
> - 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/ : fatal error LNK1120: 42 unresolved externals
>     Error executing link.exe.
> - 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 <>, 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,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message