You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2003/10/06 13:38:22 UTC
Problem building mp1 on Win32
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'
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 <cr...@yahoo.com>, 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [PATCH] Re: Problem building mp1 on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 8 Oct 2003, Steve Hay wrote:
> I think I've cracked it myself looking at those two files.
> The original .dsp file has two lines like this:
> ADD CPP ... /I "\Perl\lib\CORE" ...
> which get fixed up by Makefile.PL to this:
> ADD CPP ... /I "\Perl\lib\CORE" /I "C:\apache\include" /I
> "C:\apache\include/../os/win32" /I "C:\perl5\lib\CORE" ...
>
> Looks like that include path in the original ADD CPP lines should have
> been *changed* to "C:\perl5\lib\CORE", or at least have the correct path
> put *before* it -- it's no good having "\Perl\lib\CORE" and then
> "C:\perl5\lib\CORE" ;-)
>
> The attached patch to Makefile.PL (against 1.29-rc1) fixes those lines
> up as this:
>
> ADD CPP ... /I "C:\apache\include" /I
> "C:\apache\include/../os/win32" /I "C:\perl5\lib\CORE" ...
>
> and I can now build mp1.29-rc1 with or without the extra C:\perl in place.
Thanks, Steve! I just committed your patch in the current cvs.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[PATCH] Re: Problem building mp1 on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>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.
>
Ah, right. That makes sense, because the Perl in C:\perl5 does not have
LFS while the one in C:\perl does.
And it being fixed in cvs (and therefore in 1.29-rc1) explains the
different behaviour below.
>
>
>
>>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 <cr...@yahoo.com>, 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.
>
I think I've cracked it myself looking at those two files.
The original .dsp file has two lines like this:
ADD CPP ... /I "\Perl\lib\CORE" ...
which get fixed up by Makefile.PL to this:
ADD CPP ... /I "\Perl\lib\CORE" /I "C:\apache\include" /I
"C:\apache\include/../os/win32" /I "C:\perl5\lib\CORE" ...
Looks like that include path in the original ADD CPP lines should have
been *changed* to "C:\perl5\lib\CORE", or at least have the correct path
put *before* it -- it's no good having "\Perl\lib\CORE" and then
"C:\perl5\lib\CORE" ;-)
The attached patch to Makefile.PL (against 1.29-rc1) fixes those lines
up as this:
ADD CPP ... /I "C:\apache\include" /I
"C:\apache\include/../os/win32" /I "C:\perl5\lib\CORE" ...
and I can now build mp1.29-rc1 with or without the extra C:\perl in place.
- Steve
Re: Problem building mp1 on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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 <cr...@yahoo.com>, 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org