Re: Problem compiling mod_perl 1.27 on Windows
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
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
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
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
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