You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2002/12/16 13:02:12 UTC
Problem compiling mod_perl 1.27 on Windows
Hi,
I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
upgrade my Perl to the slightly patched sources that ActivePerl Build
804 uses. I've built Perl from these new sources with the same build
options that I used before for the standard source build (no threading,
and Perl's malloc). (The output of "Perl -V" is at the bottom of this
mail.)
I run the following commands to build mod_perl:
perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI
nmake
The first command runs fine, but the second has the following error:
Apache.xs(1963) : error C2115: '=' : incompatible types
The line referred to by this error is:
statcache = r->finfo;
I've no idea why this should be causing a problem with the new Perl. If
I switch the Perl that I'm building against back to the standard 5.8.0
(by simply re-naming directories) and then re-run the "nmake" command
above then mod_perl compiles and links with no errors.
Can anyone shed any light on this?
- Steve
=====
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_PERLIO
-DPERL_MSVCRT_READFIX',
optimize='-MD -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -release
-libpath:"C:\perl5\lib\CORE" -machine:x86'
libpth=C:\PROGRA~1\MICROS~2\VC98\lib C:\openssl\lib
libs=libeay32.lib oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
perllibs=libeay32.lib oldnames.lib kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release
-libpath:"C:\perl5\lib\CORE" -machine:x86'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under MSWin32
Compiled at Dec 13 2002 08:42:43
@INC:
C:/perl5/lib
C:/perl5/site/lib
.
Re: Problem compiling mod_perl 1.27 on Windows
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 17 Dec 2002, Steve Hay wrote:
> Randy Kobes wrote:
>
> >On Mon, 16 Dec 2002, Steve Hay wrote:
> >
> >>Is there some other way, for Win32, to achieve what the
> >>PERL_USELARGEFILES=0 hack tried to do?
> >>
> >This seems hard to do without recompiling either the standard
> >Apache sources (to enable large_files support) or else the
> >standard ActivePerl 8xx sources (to disable large_files support).
> >
> Sounds like recompiling Perl from the ActivePerl 804 sources with
> large_files support disabled is my best bet.
That would most probably fix the problem with mod_perl. Doing
this may lead to an incompatibility in principle with trying to
use a particular ppm package (having an xs component) provided by
ActiveState, but since you have a compiler, that's not a problem
for you.
> Am I correct in thinking that all I need to do to achieve this
> is change "uselargefiles='define'" back to
> "uselargefiles='undef'" in win32/config.vc, or is there
> anything else that I need to fiddle with too?
I'm not sure .... Probably the safest thing to do is to compare
the relevant files (Makefile, config*, *.h) under the win32/
subdirectory of the ActivePerl sources with those in the CPAN
Perl sources.
--
best regards,
randy
Re: Problem compiling mod_perl 1.27 on Windows
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Mon, 16 Dec 2002, Steve Hay wrote:
>
>
>>Is there some other way, for Win32, to achieve what the
>>PERL_USELARGEFILES=0 hack tried to do?
>>
>>
>This seems hard to do without recompiling either the standard
>Apache sources (to enable large_files support) or else the
>standard ActivePerl 8xx sources (to disable large_files support).
>
Sounds like recompiling Perl from the ActivePerl 804 sources with
large_files support disabled is my best bet.
Am I correct in thinking that all I need to do to achieve this is change
"uselargefiles='define'" back to "uselargefiles='undef'" in
win32/config.vc, or is there anything else that I need to fiddle with too?
- Steve
Re: Problem compiling mod_perl 1.27 on Windows
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 16 Dec 2002, Steve Hay wrote:
> Randy Kobes wrote:
> >
> >I've found the same thing - I believe it's because of the
> >USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
> >runs into a conflict with the standard Win32 apache-1 which
> >doesn't have such support (in the above, statcache is from the
> >Perl side, and r->finfo is from Apache). This is still being
> >looked into ...
> >
> >One possibility is to recompile Apache with large_file support,
> >but this is non-trivial. And since the bulk of Win32 development
> >on Apache is going into Apache-2, it may be hard to get an Apache
> >developer to look at this.
> >
> Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
> uselargefiles_check() routine that originally warned about conflicts,
> but now (as of 1.27, according to the Changes file) automatically sets
> PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
> that this seems to make is to stop Perl's $Config{ccflags} from being
> appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
> $Config{ccflags} doesn't mention anything to do with large_files, so
> it's hardly surprising that disaster is not averted (if this is indeed
> the problem).
That's true - Perl's ccflags don't mention USE_LARGE_FILES; it
only gets mentioned in the compile-time options.
> Is there some other way, for Win32, to achieve what the
> PERL_USELARGEFILES=0 hack tried to do?
This seems hard to do without recompiling either the standard
Apache sources (to enable large_files support) or else the
standard ActivePerl 8xx sources (to disable large_files support).
One possibility is to define one's own statcache (presently
defined in the header files under /Perl/lib/CORE/) as is defined
in a Win32 Perl without large_files support. That may get around
the problem in Apache.xs about incompatible types between
statcache and r->finfo, but this might lead to other problems
later.
> I also see that the warning that was originally output by
> uselargefiles_check() suggested re-building Apache with
> large_files support by simply specifying a couple of extra
> defines. I take it from what you're saying that it isn't quite
> as trivial as that on Win32?
I tried just adding a couple of extra defines in compiling apache
- this starts a series of error messages in various C files about
incompatibilities, which then leads to having to put in a bunch
of #ifdef ... statemements. Ultimately this probably could be
worked out, but I'd be very uncomfortable using such a hacked
version without some official Apache support.
> >By the way, mod_perl-2 (for use with Apache2) compiles fine with
> >the ActivePerl sources.
> >
> >
> I've been reluctant to use mod_perl 2 for anything more than testing
> purposes yet because its current version number (1.99_07) doesn't fill
> me with confidence that it's sufficiently stable. The mod_perl setup
> that I'm trying to build is destined for a production environment, so
> I'd rather stick to more tried and tested things for now.
>
> I would be interested to hear how stable people think mod_perl 2
> currently is on Win32.
That would be interesting ....
--
best regards,
randy
Re: Problem compiling mod_perl 1.27 on Windows
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Mon, 16 Dec 2002, Steve Hay wrote:
>
>
>>I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
>>5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
>>
>>It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
>>upgrade my Perl to the slightly patched sources that ActivePerl Build
>>804 uses. I've built Perl from these new sources with the same build
>>options that I used before for the standard source build (no threading,
>>and Perl's malloc). (The output of "Perl -V" is at the bottom of this
>>mail.)
>>
>>
>[ .. ]
>
>
>>Characteristics of this binary (from libperl):
>> Compile-time options: USE_LARGE_FILES
>>
>>
>
>I've found the same thing - I believe it's because of the
>USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
>runs into a conflict with the standard Win32 apache-1 which
>doesn't have such support (in the above, statcache is from the
>Perl side, and r->finfo is from Apache). This is still being
>looked into ...
>
>One possibility is to recompile Apache with large_file support,
>but this is non-trivial. And since the bulk of Win32 development
>on Apache is going into Apache-2, it may be hard to get an Apache
>developer to look at this.
>
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with large_files
support by simply specifying a couple of extra defines. I take it from
what you're saying that it isn't quite as trivial as that on Win32?
>By the way, mod_perl-2 (for use with Apache2) compiles fine with
>the ActivePerl sources.
>
>
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
- Steve
Re: Problem compiling mod_perl 1.27 on Windows
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 16 Dec 2002, Steve Hay wrote:
> Hi,
>
> I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
> 5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
>
> It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
> upgrade my Perl to the slightly patched sources that ActivePerl Build
> 804 uses. I've built Perl from these new sources with the same build
> options that I used before for the standard source build (no threading,
> and Perl's malloc). (The output of "Perl -V" is at the bottom of this
> mail.)
>
> I run the following commands to build mod_perl:
>
> perl Makefile.PL APACHE_SRC=C:/apache
> INSTALL_DLL=C:/apache/modules EAPI
> nmake
>
> The first command runs fine, but the second has the following error:
>
> Apache.xs(1963) : error C2115: '=' : incompatible types
>
> The line referred to by this error is:
>
> statcache = r->finfo;
>
> I've no idea why this should be causing a problem with the new
> Perl. If I switch the Perl that I'm building against back to
> the standard 5.8.0 (by simply re-naming directories) and then
> re-run the "nmake" command above then mod_perl compiles and
> links with no errors.
>
> Can anyone shed any light on this?
>
> - Steve
[ .. ]
> Characteristics of this binary (from libperl):
> Compile-time options: USE_LARGE_FILES
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r->finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
--
best regards,
randy kobes