You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/04/01 06:59:25 UTC
large file support
hi all
I've traced the 2.1 issue reported on modperl@ (and seen by both philippe
and I) down to this APR change:
http://marc.theaimsgroup.com/?l=apr-cvs&m=108039307912906&w=2
building Apache with --disable-lfs puts everything back to normal.
now, I'm not sure whether the problem is with APR, or if all of a sudden the
automagical intuition of off_t foo is interfering with some assumptions
mod_perl makes. in either case, it's something that we need to resolve so
we work with APR 1.0.
ideas welcome.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Wed, Apr 07, 2004 at 01:44:23PM -0700, Stas Bekman wrote:
>
>>Joe Orton wrote:
>>
>>>The issue with the echo.t test on Solaris is that the socket is in
>>>non-blocking mode on the server, so on the second recv() the server just
>>>returns EINTR as there's no data available.
>>
>>Coolio, Joe. So should we set some socket args to make it blocking before
>>calling recv()?
>
>
> Yeah, I reckon so. Fixes echo.t on Solaris and still works on Linux:
>
> --- t/protocol/TestProtocol/echo.pm 11 Apr 2002 11:08:43 -0000 1.2
> +++ t/protocol/TestProtocol/echo.pm 7 Apr 2004 20:50:55 -0000
> @@ -7,6 +7,7 @@
> use APR::Socket ();
>
> use Apache::Const -compile => 'OK';
> +use APR::Const -compile => qw(:socket);
>
> use constant BUFF_LEN => 1024;
>
> @@ -15,6 +16,8 @@
> my APR::Socket $socket = $c->client_socket;
>
> my $buff;
> +
> + $socket->opt_set(APR::SO_NONBLOCK, 0);
>
> for (;;) {
> my($rlen, $wlen);
joe++
And we get to exercise socket functions, which is nice!
I'll add a comment, so we don't forget why we do that.
# on some platforms (OSX/Solaris) httpd hands us a non-blocking socket
It's funny how you need to set a nonblocking option to zero to get the
blocking effect.
>>>but... the fact that this works on Linux means that the socket has been
>>>left in blocking mode there, and it shouldn't be AFAIK, so I'm confused
>>>about that.
>>
>>Nothing on the modperl side, that's what httpd gives to us.
>
>
> Hmmm, right. It's supposed to be like that. You get a non-blocking
> socket on some platforms, and a blocking socket on others. Screwy, eh?
Not very friendly to a developer who gets to access on a specific platform. Is
this documented somewhere?
> But for echo_filter.pm, the ap_brigade_get() is being passed
> AP_BLOCK_READ by default, so now I'll go and find out why that doesn't
> work as you'd expect...
cool! looks like we need to load:
use Apache::Filter ();
as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Apr 07, 2004 at 01:44:23PM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >The issue with the echo.t test on Solaris is that the socket is in
> >non-blocking mode on the server, so on the second recv() the server just
> >returns EINTR as there's no data available.
>
> Coolio, Joe. So should we set some socket args to make it blocking before
> calling recv()?
Yeah, I reckon so. Fixes echo.t on Solaris and still works on Linux:
--- t/protocol/TestProtocol/echo.pm 11 Apr 2002 11:08:43 -0000 1.2
+++ t/protocol/TestProtocol/echo.pm 7 Apr 2004 20:50:55 -0000
@@ -7,6 +7,7 @@
use APR::Socket ();
use Apache::Const -compile => 'OK';
+use APR::Const -compile => qw(:socket);
use constant BUFF_LEN => 1024;
@@ -15,6 +16,8 @@
my APR::Socket $socket = $c->client_socket;
my $buff;
+
+ $socket->opt_set(APR::SO_NONBLOCK, 0);
for (;;) {
my($rlen, $wlen);
> >but... the fact that this works on Linux means that the socket has been
> >left in blocking mode there, and it shouldn't be AFAIK, so I'm confused
> >about that.
>
> Nothing on the modperl side, that's what httpd gives to us.
Hmmm, right. It's supposed to be like that. You get a non-blocking
socket on some platforms, and a blocking socket on others. Screwy, eh?
But for echo_filter.pm, the ap_brigade_get() is being passed
AP_BLOCK_READ by default, so now I'll go and find out why that doesn't
work as you'd expect...
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> The issue with the echo.t test on Solaris is that the socket is in
> non-blocking mode on the server, so on the second recv() the server just
> returns EINTR as there's no data available.
Coolio, Joe. So should we set some socket args to make it blocking before
calling recv()?
> but... the fact that this works on Linux means that the socket has been
> left in blocking mode there, and it shouldn't be AFAIK, so I'm confused
> about that.
Nothing on the modperl side, that's what httpd gives to us.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
The issue with the echo.t test on Solaris is that the socket is in
non-blocking mode on the server, so on the second recv() the server just
returns EINTR as there's no data available.
but... the fact that this works on Linux means that the socket has been
left in blocking mode there, and it shouldn't be AFAIK, so I'm confused
about that.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Wed, Apr 07, 2004 at 09:51:56AM -0700, Stas Bekman wrote:
>
>>Joe Orton wrote:
>
> ...
>
>>>t/filter/both_str_con_add.t 4 2 50.00% 3-4
>>>t/protocol/echo.t 3 1 33.33% 3
>>>t/protocol/echo_filter.t 3 1 33.33% 3
>>
>>These three has to do with some bug in APR sockets. All three implement a
>>protocol handler which reads/writes raw connection sockets. It works just
>>fine on several unices, but fails on Solaris and OSX.
>>
>>
>>>any of these known failures and/or worth looking at?
>>
>>They are known failures, but nobody is working on them. If you would like
>>to help to resolve these, that would be fantastic. I can guide you of what
>>to loook at if you decide to help.
>
>
> Hey, it's a rainy evening... how far have you debugged this so far then?
I haven't at all, since they don't fail on linux. The only additional
information I have from one of the users on Solaris that IO::Socket works fine
on its own (which is what happens on the client side), so it must be a fault
of the APR socket API on the server side. And the perl glue just calls C
functions, so it's probably some C API problems.
So what I suspect is that the client socket using perl's IO::Socket works fine
, and one needs to breakpoint into APR::Socket and run the echo.t test and
step through to see where the data doesn't get through. echo.t is the simplest
possible test, perfectly suitable for this job.
Please take a look at the precooked gdb scripts to make your debugging easier:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts
and
http://perl.apache.org/docs/2.0/devel/debug/c.html#Debug_notes
in general (but you probably know most of this already :)
>>But it's good to see that the rest is working. Also please test the LFS
>>thingy with httpd-2.1, as you said it'd have worked just fine with 2.0, but
>>not with 2.1 before we did all these recent changes.
>
>
> The CFLAGS thing with using APR HEAD regardless of whether Perl itself
> was built with LFS. I'm now building 5.8.3 with -Duselargefiles for
> comparison.
oh, you are using APR head with httpd 2.0?
>>>the core dump was actually created by the 'perl' binary rather than
>>>'httpd'...
>>
>>core dump? Can we see a backtrace?
>
>
> FWIW, it looked like this, not sure I believe it really got into
> libthread.
>
> #0 0xdfddf70c in _bind_guard () from /usr/lib/libthread.so.1
> #1 0xdffeae65 in ?? ()
> #2 0xdfff0c7f in ?? ()
> #3 0xdffe6559 in ?? ()
> #4 0x80a46a5 in Perl_pp_entersub ()
> #5 0x80633f9 in S_call_body ()
> #6 0x80631d2 in Perl_call_sv ()
> #7 0x80aa594 in Perl_sv_clear ()
> #8 0x80aaacd in Perl_sv_free ()
> #9 0x80bb90d in Perl_free_tmps ()
> #10 0x80628e1 in perl_run ()
> #11 0x8060295 in main ()
> #12 0x80600d7 in _start ()
looks like some corrupted frames core. we need to figure out the cause. running:
t/SMOKE -v
will check for the core file after each test is run, so it may help to
pinpoint the cause.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Apr 07, 2004 at 09:51:56AM -0700, Stas Bekman wrote:
> Joe Orton wrote:
...
> >t/filter/both_str_con_add.t 4 2 50.00% 3-4
> >t/protocol/echo.t 3 1 33.33% 3
> >t/protocol/echo_filter.t 3 1 33.33% 3
>
> These three has to do with some bug in APR sockets. All three implement a
> protocol handler which reads/writes raw connection sockets. It works just
> fine on several unices, but fails on Solaris and OSX.
>
> >any of these known failures and/or worth looking at?
>
> They are known failures, but nobody is working on them. If you would like
> to help to resolve these, that would be fantastic. I can guide you of what
> to loook at if you decide to help.
Hey, it's a rainy evening... how far have you debugged this so far then?
> But it's good to see that the rest is working. Also please test the LFS
> thingy with httpd-2.1, as you said it'd have worked just fine with 2.0, but
> not with 2.1 before we did all these recent changes.
The CFLAGS thing with using APR HEAD regardless of whether Perl itself
was built with LFS. I'm now building 5.8.3 with -Duselargefiles for
comparison.
> >the core dump was actually created by the 'perl' binary rather than
> >'httpd'...
>
> core dump? Can we see a backtrace?
FWIW, it looked like this, not sure I believe it really got into
libthread.
#0 0xdfddf70c in _bind_guard () from /usr/lib/libthread.so.1
#1 0xdffeae65 in ?? ()
#2 0xdfff0c7f in ?? ()
#3 0xdffe6559 in ?? ()
#4 0x80a46a5 in Perl_pp_entersub ()
#5 0x80633f9 in S_call_body ()
#6 0x80631d2 in Perl_call_sv ()
#7 0x80aa594 in Perl_sv_clear ()
#8 0x80aaacd in Perl_sv_free ()
#9 0x80bb90d in Perl_free_tmps ()
#10 0x80628e1 in perl_run ()
#11 0x8060295 in main ()
#12 0x80600d7 in _start ()
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> With a HEAD of 2.0 and mod_perl built on Solaris 7/x86 against Perl
> 5.6.1 (-Uuselargefiles) I got:
>
> Failed Test Status Wstat Total Fail Failed List of
> Failed
> --------------------------------------------------------------------------------
> t/apr-ext/uuid.t 0 139 3 0 0.00% ??
This one has to do with linking, it's testing the Perl glue for APR, which can
run outside of Apache/mod_perl (e.g. from the command line).
> t/filter/both_str_con_add.t 4 2 50.00% 3-4
> t/protocol/echo.t 3 1 33.33% 3
> t/protocol/echo_filter.t 3 1 33.33% 3
These three has to do with some bug in APR sockets. All three implement a
protocol handler which reads/writes raw connection sockets. It works just fine
on several unices, but fails on Solaris and OSX.
> any of these known failures and/or worth looking at?
They are known failures, but nobody is working on them. If you would like to
help to resolve these, that would be fantastic. I can guide you of what to
loook at if you decide to help.
But it's good to see that the rest is working. Also please test the LFS thingy
with httpd-2.1, as you said it'd have worked just fine with 2.0, but not with
2.1 before we did all these recent changes.
> the core dump was actually created by the 'perl' binary rather than
> 'httpd'...
core dump? Can we see a backtrace?
Thanks Joe.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> 5.6.1 is ok for prefork but 5.8.0 is required for threaded MPMs, so if
> you're on worker all bets are off :) if on prefork maybe the dump has
> something to do with what stas already knows.
Makefile.PL won't let you build against the worker mpm unless you use 5.8.0+
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> With a HEAD of 2.0 and mod_perl built on Solaris 7/x86 against Perl
> 5.6.1 (-Uuselargefiles) I got:
>
> Failed Test Status Wstat Total Fail Failed List of
> Failed
> --------------------------------------------------------------------------------
> t/apr-ext/uuid.t 0 139 3 0 0.00% ??
> t/filter/both_str_con_add.t 4 2 50.00% 3-4
> t/protocol/echo.t 3 1 33.33% 3
> t/protocol/echo_filter.t 3 1 33.33% 3
> 27 tests skipped.
failures from this group seems to be pretty common on certain platforms. I
think stas knows what the problem is but just hasn't had the time.
> [warning] server localhost:8529 shutdown
> [ error] error running tests (please examine t/logs/error_log)
> [ error] oh golly, server dumped core
>
> any of these known failures and/or worth looking at?
>
> the core dump was actually created by the 'perl' binary rather than
> 'httpd'...
5.6.1 is ok for prefork but 5.8.0 is required for threaded MPMs, so if
you're on worker all bets are off :) if on prefork maybe the dump has
something to do with what stas already knows.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
With a HEAD of 2.0 and mod_perl built on Solaris 7/x86 against Perl
5.6.1 (-Uuselargefiles) I got:
Failed Test Status Wstat Total Fail Failed List of
Failed
--------------------------------------------------------------------------------
t/apr-ext/uuid.t 0 139 3 0 0.00% ??
t/filter/both_str_con_add.t 4 2 50.00% 3-4
t/protocol/echo.t 3 1 33.33% 3
t/protocol/echo_filter.t 3 1 33.33% 3
27 tests skipped.
[warning] server localhost:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
[ error] oh golly, server dumped core
any of these known failures and/or worth looking at?
the core dump was actually created by the 'perl' binary rather than
'httpd'...
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> OK I've committed your suggestion and tested with the latest 2.0 and 2.1
> of prefork mpm. So whenever you have a chance please test on Solaris.
> Thanks!
works fine for me on fedora. nice work guys.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Mon, Apr 05, 2004 at 01:11:05PM -0700, Stas Bekman wrote:
>
>>Joe Orton wrote:
>>[...]
>>
>>>If you want to be conservative, just stick with EXTRA_CPPFLAGS; this
>>>should be sufficient to make sure apr.h can be safely included. The
>>>problem is if you use EXTRA_CFLAGS you need NOTEST_CPPFLAGS normally,
>>>since the latter prevents some GCC warnings which the former will
>>>induce.
>>
>>Thanks, Joe. I'm now testing with this conservative idea. Do you have an
>>access to Solaris, to give it a try once I polish it on linux?
>
>
> Yes, I should be able to do that at some point.
OK I've committed your suggestion and tested with the latest 2.0 and 2.1 of
prefork mpm. So whenever you have a chance please test on Solaris. Thanks!
>>>>>Finally the ccopts function could do with doing some normalization of
>>>>>the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
>>>>>will be used twice otherwise.
>>>>
>>>>Sure, I'll do that. But is there any harm in those duplicates?
>>>
>>>
>>>Probably not, no. It's just a cosmetic thing really.
>>
>>It's going to be a tricky thing to do, besides the obvious 1:1 dups. How
>>should we deal with cases like:
>>-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
>>-Werror
>>
>>-Wall added by mod_perl, the rest are by apache. I think when -Wall is in
>>place, the rest of -W can be removed, but may be there are extra -W flags
>>which aren't included by -Wall?
>
>
> Yes, those named above actually are all warning flags which are not
> implied by -Wall.
That's what I thought, thanks! so much for 'all'
>>or cases when we have:
>>
>>-O0 and -O2
>>
>>Should we pick -O2 or -O0? What gcc does when it sees both options?
>
>
> Probably the first listed in argv wins... or maybe the last. Really,
> this duplication thing is not important to fix at all, I wouldn't worry
> about it, I shouldn't have brought it up.
well, I handled the simple dups like:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 05, 2004 at 01:11:05PM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> [...]
> >If you want to be conservative, just stick with EXTRA_CPPFLAGS; this
> >should be sufficient to make sure apr.h can be safely included. The
> >problem is if you use EXTRA_CFLAGS you need NOTEST_CPPFLAGS normally,
> >since the latter prevents some GCC warnings which the former will
> >induce.
>
> Thanks, Joe. I'm now testing with this conservative idea. Do you have an
> access to Solaris, to give it a try once I polish it on linux?
Yes, I should be able to do that at some point.
> [...]
>
> >>>Finally the ccopts function could do with doing some normalization of
> >>>the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
> >>>will be used twice otherwise.
> >>
> >>Sure, I'll do that. But is there any harm in those duplicates?
> >
> >
> >Probably not, no. It's just a cosmetic thing really.
>
> It's going to be a tricky thing to do, besides the obvious 1:1 dups. How
> should we deal with cases like:
> -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
> -Werror
>
> -Wall added by mod_perl, the rest are by apache. I think when -Wall is in
> place, the rest of -W can be removed, but may be there are extra -W flags
> which aren't included by -Wall?
Yes, those named above actually are all warning flags which are not
implied by -Wall.
> or cases when we have:
>
> -O0 and -O2
>
> Should we pick -O2 or -O0? What gcc does when it sees both options?
Probably the first listed in argv wins... or maybe the last. Really,
this duplication thing is not important to fix at all, I wouldn't worry
about it, I shouldn't have brought it up.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 05, 2004 at 02:00:58PM -0700, Stas Bekman wrote:
...
> >>since we look for /-D_FILE_OFFSET_BITS=64/ and we don't find it on the
> >>apache side we strip /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/, but
> >>now that I've added EXTRA_CPPFLAGS, I get -D_LARGEFILE64_SOURCE pushed
> >>in. Isn't that a problem? We strip -D_LARGEFILE_SOURCE but add
> >>-D_LARGEFILE64_SOURCE? Aren't the two indicated the same thing?
> >
> >
> >No, they're different, and no, it isn't a problem, that's exactly the
> >desired outcome.
> >
> >good: -D_LARGEFILE64_SOURCE
> > bad: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> Ah, OK. I got the -D_FILE_OFFSET_BITS=64 part, but thought that
> -D_LARGEFILE_SOURCE is a different story. If I remember correctly you've
> suggested to strip only the -D_FILE_OFFSET_BITS=64 part
>
> if ($perl_lfs64 && !$apr_lfs64) {
> # Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
> }
>
> I did keep the strip of the whole /-D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64/
Sorry, my mistake: yes, stripping the whole thing is correct.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> I think I answered this one pre-emptively in my "background" post :)
>
> On Mon, Apr 05, 2004 at 01:33:16PM -0700, Stas Bekman wrote:
>
>>There is one more bit that is not clear to me:
>>
>>httpd 2.1 gives me: -D_LARGEFILE64_SOURCE
>
>
> ... this is what's needed for using approach (2) to Doing LFS
>
>
>>perl gives me: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
>
> ... this is what's needed for using approach (1) to Doing LFS
>
>
>>since we look for /-D_FILE_OFFSET_BITS=64/ and we don't find it on the
>>apache side we strip /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/, but now
>>that I've added EXTRA_CPPFLAGS, I get -D_LARGEFILE64_SOURCE pushed in.
>>Isn't that a problem? We strip -D_LARGEFILE_SOURCE but add
>>-D_LARGEFILE64_SOURCE? Aren't the two indicated the same thing?
>
>
> No, they're different, and no, it isn't a problem, that's exactly the
> desired outcome.
>
> good: -D_LARGEFILE64_SOURCE
> bad: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Ah, OK. I got the -D_FILE_OFFSET_BITS=64 part, but thought that
-D_LARGEFILE_SOURCE is a different story. If I remember correctly you've
suggested to strip only the -D_FILE_OFFSET_BITS=64 part
if ($perl_lfs64 && !$apr_lfs64) {
# Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
}
I did keep the strip of the whole /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Gedanken wrote:
> On Mon, 5 Apr 2004, Joe Orton wrote:
>
> No, they're different, and no, it isn't a problem, that's exactly the
> desired outcome.
>
> good: -D_LARGEFILE64_SOURCE
> bad: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> I dont know why but I have read this entire thread hoping to learn
> *something cool, not sure what*
>
> But my head just exploded all over my monitor and HR is not amused =(
>
> Kudos to you both for helping sort this stuff out so I can remain
> blissfully ignorant to such issues in the future =) I will contribute one
> day but it sure as heck wont be related to LFS issues, apsx and gcc
> flags.
Believe me, I too want to be ignorant of these issues :) It'd be really nice
to have an integration expert dealing with this kind of issues, and let us go
free and just do the app coding :)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Gedanken <ge...@io.com>.
On Mon, 5 Apr 2004, Joe Orton wrote:
No, they're different, and no, it isn't a problem, that's exactly the
desired outcome.
good: -D_LARGEFILE64_SOURCE
bad: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
I dont know why but I have read this entire thread hoping to learn
*something cool, not sure what*
But my head just exploded all over my monitor and HR is not amused =(
Kudos to you both for helping sort this stuff out so I can remain
blissfully ignorant to such issues in the future =) I will contribute one
day but it sure as heck wont be related to LFS issues, apsx and gcc
flags.
/wink
matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
I think I answered this one pre-emptively in my "background" post :)
On Mon, Apr 05, 2004 at 01:33:16PM -0700, Stas Bekman wrote:
> There is one more bit that is not clear to me:
>
> httpd 2.1 gives me: -D_LARGEFILE64_SOURCE
... this is what's needed for using approach (2) to Doing LFS
> perl gives me: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
... this is what's needed for using approach (1) to Doing LFS
> since we look for /-D_FILE_OFFSET_BITS=64/ and we don't find it on the
> apache side we strip /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/, but now
> that I've added EXTRA_CPPFLAGS, I get -D_LARGEFILE64_SOURCE pushed in.
> Isn't that a problem? We strip -D_LARGEFILE_SOURCE but add
> -D_LARGEFILE64_SOURCE? Aren't the two indicated the same thing?
No, they're different, and no, it isn't a problem, that's exactly the
desired outcome.
good: -D_LARGEFILE64_SOURCE
bad: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
[...]
> If you want to be conservative, just stick with EXTRA_CPPFLAGS; this
> should be sufficient to make sure apr.h can be safely included. The
> problem is if you use EXTRA_CFLAGS you need NOTEST_CPPFLAGS normally,
> since the latter prevents some GCC warnings which the former will
> induce.
Thanks, Joe. I'm now testing with this conservative idea. Do you have an
access to Solaris, to give it a try once I polish it on linux?
[...]
>>>Finally the ccopts function could do with doing some normalization of
>>>the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
>>>will be used twice otherwise.
>>
>>Sure, I'll do that. But is there any harm in those duplicates?
>
>
> Probably not, no. It's just a cosmetic thing really.
It's going to be a tricky thing to do, besides the obvious 1:1 dups. How
should we deal with cases like:
-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Werror
-Wall added by mod_perl, the rest are by apache. I think when -Wall is in
place, the rest of -W can be removed, but may be there are extra -W flags
which aren't included by -Wall?
or cases when we have:
-O0 and -O2
Should we pick -O2 or -O0? What gcc does when it sees both options?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 05, 2004 at 11:30:19AM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >Great. It looks like mod_perl is not pulling in all the right variables
> >from apxs though still. APR HEAD will break if -D_LARGEFILE64_SOURCE is
> >not defined when including apr.h on many platforms. On Linux you get
> >away with it because Perl defines -D_GNU_SOURCE which implies
> >-D_LARGEFILE64_SOURCE, but this won't happen on Solaris etc.
> >
> >I can fix it by continuing the copy'n'paste-fest as below, but I had to
> >change the apxs function to not give errors for a -q output which was
> >empty, which is not an error in some cases, e.g. -q NOTEST_CFLAGS,
> >though is an error in others I suppose, -q INCLUDEDIR etc.
>
> Why isn't -D_LARGEFILE64_SOURCE in the normal flags? Asking for obscure
> NOTEST_* flags doesn't sound very obvious.
Sorry, I wasn't clear about this. For reference, here's what I get from
a HEAD build (which used --enable-maintainer-mode, hence has lots of
-Wfoo)
$ for f in CFLAGS EXTRA_CFLAGS EXTRA_CPPFLAGS NOTEST_CFLAGS NOTEST_CPPFLAGS; do echo $f = `bin/apxs -q $f`; done
CFLAGS = -g -O2 -Wall -I/usr/kerberos/include
EXTRA_CFLAGS = -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread
EXTRA_CPPFLAGS = -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -DAP_DEBUG
NOTEST_CFLAGS =
NOTEST_CPPFLAGS = -DAP_HAVE_DESIGNATED_INITIALIZER
at the moment, mod_perl is not using *any* of those variables in
ap_ccopts, which is bad; in fact the apxs_cflags function in Build.pm
seems to be completely unused.
If you want to be conservative, just stick with EXTRA_CPPFLAGS; this
should be sufficient to make sure apr.h can be safely included. The
problem is if you use EXTRA_CFLAGS you need NOTEST_CPPFLAGS normally,
since the latter prevents some GCC warnings which the former will
induce.
Any modules which build using "apxs -c" already use most of the above:
my $CFG_CFLAGS = join ' ', map { get_vars($_) }
qw(SHLTCFLAGS CFLAGS NOTEST_CPPFLAGS EXTRA_CPPFLAGS EXTRA_CFLAGS);
(SHLTCFLAGS is inappropriate for mod_perl as it's libtool-specific)
> >Finally the ccopts function could do with doing some normalization of
> >the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
> >will be used twice otherwise.
>
> Sure, I'll do that. But is there any harm in those duplicates?
Probably not, no. It's just a cosmetic thing really.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
There is one more bit that is not clear to me:
httpd 2.1 gives me: -D_LARGEFILE64_SOURCE
perl gives me: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
since we look for /-D_FILE_OFFSET_BITS=64/ and we don't find it on the apache
side we strip /-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/, but now that I've
added EXTRA_CPPFLAGS, I get -D_LARGEFILE64_SOURCE pushed in. Isn't that a
problem? We strip -D_LARGEFILE_SOURCE but add -D_LARGEFILE64_SOURCE? Aren't
the two indicated the same thing?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Sun, Apr 04, 2004 at 09:40:18PM -0700, Stas Bekman wrote:
>
>>Joe Orton wrote:
>>
>>>OK, let's do the background... on Unix systems where by default off_t is
>>>a "long", a 32-bit integer, there are two different ways to get "large
>>>file" support, i.e. the ability to manipulate files bigger than 2Gb:
>>
>>Muchas Gracias, Joe. I've committed both your explanation and the logic
>>which now works fine with both, 2.0 and 2.1.
>
>
> Great. It looks like mod_perl is not pulling in all the right variables
> from apxs though still. APR HEAD will break if -D_LARGEFILE64_SOURCE is
> not defined when including apr.h on many platforms. On Linux you get
> away with it because Perl defines -D_GNU_SOURCE which implies
> -D_LARGEFILE64_SOURCE, but this won't happen on Solaris etc.
>
> I can fix it by continuing the copy'n'paste-fest as below, but I had to
> change the apxs function to not give errors for a -q output which was
> empty, which is not an error in some cases, e.g. -q NOTEST_CFLAGS,
> though is an error in others I suppose, -q INCLUDEDIR etc.
Why isn't -D_LARGEFILE64_SOURCE in the normal flags? Asking for obscure
NOTEST_* flags doesn't sound very obvious.
> By picking up NOTEST_{C,CPP}FLAGS the code to add -DAP_DEBUG and
> -DAP_HAVE_DESIGNATED_INITIALIZER could/should now be removed too.
> AP_HAVE_DESIGNATED_INITIALIZER will be always added when appropriate
> with this applied since it's in NOTEST_CPPFLAGS.
>
> I'm not sure it's necessarily safe to add AP_DEBUG if httpd was not
> itself built with AP_DEBUG; there were issues with this in the past.
I don't like that idea. Later some other defines will be put there and we will
have a macaroni of fishing them out.
What are the chances that -D_LARGEFILE64_SOURCE will migrate to
EXTRA_CPPFLAGS, or some other place which can be used as is?
> Finally the ccopts function could do with doing some normalization of
> the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
> will be used twice otherwise.
Sure, I'll do that. But is there any harm in those duplicates?
> There, I think I've suggested enough work for other people to do now :)
>
> Index: lib/Apache/Build.pm
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/lib/Apache/Build.pm,v
> retrieving revision 1.158
> diff -u -r1.158 Build.pm
> --- lib/Apache/Build.pm 5 Apr 2004 04:38:29 -0000 1.158
> +++ lib/Apache/Build.pm 5 Apr 2004 08:49:46 -0000
> @@ -167,7 +167,7 @@
> my $val = qx($apxs @_ 2>$devnull);
> chomp $val if defined $val; # apxs post-2.0.40 adds a new line
>
> - unless ($val) {
> + unless ($val || $is_query) {
> error "'$apxs @_' failed:";
that obliterates the whole error checking. I suppose one needs to run:
my $error = qx($apxs @_ 1>$devnull );
and rerun qx($apxs @_ 2>$devnull)
only if there is no error
though it slows things down, as it'll need to run twice as many apxs queries.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Apr 04, 2004 at 09:40:18PM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >OK, let's do the background... on Unix systems where by default off_t is
> >a "long", a 32-bit integer, there are two different ways to get "large
> >file" support, i.e. the ability to manipulate files bigger than 2Gb:
>
> Muchas Gracias, Joe. I've committed both your explanation and the logic
> which now works fine with both, 2.0 and 2.1.
Great. It looks like mod_perl is not pulling in all the right variables
from apxs though still. APR HEAD will break if -D_LARGEFILE64_SOURCE is
not defined when including apr.h on many platforms. On Linux you get
away with it because Perl defines -D_GNU_SOURCE which implies
-D_LARGEFILE64_SOURCE, but this won't happen on Solaris etc.
I can fix it by continuing the copy'n'paste-fest as below, but I had to
change the apxs function to not give errors for a -q output which was
empty, which is not an error in some cases, e.g. -q NOTEST_CFLAGS,
though is an error in others I suppose, -q INCLUDEDIR etc.
By picking up NOTEST_{C,CPP}FLAGS the code to add -DAP_DEBUG and
-DAP_HAVE_DESIGNATED_INITIALIZER could/should now be removed too.
AP_HAVE_DESIGNATED_INITIALIZER will be always added when appropriate
with this applied since it's in NOTEST_CPPFLAGS.
I'm not sure it's necessarily safe to add AP_DEBUG if httpd was not
itself built with AP_DEBUG; there were issues with this in the past.
Finally the ccopts function could do with doing some normalization of
the union of the perl/Apache CFLAGS now since "-g -O2 -D_GNU_SOURCE" etc
will be used twice otherwise.
There, I think I've suggested enough work for other people to do now :)
Index: lib/Apache/Build.pm
===================================================================
RCS file: /home/cvspublic/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.158
diff -u -r1.158 Build.pm
--- lib/Apache/Build.pm 5 Apr 2004 04:38:29 -0000 1.158
+++ lib/Apache/Build.pm 5 Apr 2004 08:49:46 -0000
@@ -167,7 +167,7 @@
my $val = qx($apxs @_ 2>$devnull);
chomp $val if defined $val; # apxs post-2.0.40 adds a new line
- unless ($val) {
+ unless ($val || $is_query) {
error "'$apxs @_' failed:";
if (my $error = qx($apxs @_ 2>&1)) {
@@ -199,6 +199,18 @@
$flags;
}
+sub apxs_notest_cflags {
+ my $flags = __PACKAGE__->apxs('-q' => 'NOTEST_CFLAGS');
+ $flags =~ s/\"/\\\"/g;
+ $flags;
+}
+
+sub apxs_notest_cppflags {
+ my $flags = __PACKAGE__->apxs('-q' => 'NOTEST_CPPFLAGS');
+ $flags =~ s/\"/\\\"/g;
+ $flags;
+}
+
my %threaded_mpms = map { $_ => 1}
qw(worker winnt beos mpmt_os2 netware leader perchild threadpool);
sub mpm_is_threaded {
@@ -372,6 +384,12 @@
sub ap_ccopts {
my($self) = @_;
my $ccopts = "-DMOD_PERL";
+
+ $ccopts .= " " . join(" ",
+ $self->apxs_cflags, $self->apxs_extra_cflags,
+ $self->apxs_extra_cppflags,
+ $self->apxs_notest_cflags,
+ $self->apxs_notest_cppflags);
if ($self->{MP_USE_GTOP}) {
$ccopts .= " -DMP_USE_GTOP";
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Sun, Apr 04, 2004 at 09:51:38PM -0700, Stas Bekman wrote:
>
>>Geoffrey Young wrote:
>>
>>>you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags
>>>and perl recompiled, not that mod_perl can get away with simply not
>>>including that value when it itself is compiled. if it were stripped only
>>>in mod_perl compilation you would have conflicting definitions of off_t in
>>>the two sources - long long in perl and int in mod_perl/APR.
>>
>>No Joe is talking about mod_perl only. It's not a problem to use perl and
>>mod_perl mismatching as long as we don't interface apis which use off_t,
>>like seek(). In which case we croak, just as before. The logic here didn't
>>change.
>
>
> Actually, I am surprised that mod_perl can get away with stripping
> -D_F_O_B=64 from the Perl cflags, but it seems like it can.
>
> If there are any places in the Perl C API where an Off_t is taken, Perl
> will be passed a long when it was expecting a long long in this case: so
> there are potential problems here.
>
> Hmmm... looks like the PerlIOBuf structure has an Off_t in it, so using
> that in mod_perl could be problematic. In general on x86 maybe you just
> get away with the long vs long long mismatch in passed vs expected
> function arguments/return values.
The only time we have the problem is when passing arguments between functions
operating on off_t and similar arguments. Most of the time this doesn't
happen. Only in APR perlio layers we had to disallow seek on non-zero
arguments if there is a conflict. (probably also in Apache::PerlIO, but I
doubt anybody is going to seek on STD streams, which is it used for).
We don't use PerlIOBuf, but a subclass of it in Apache::PerlIO and APR::PerlIO
layer. This subclass directly calls apache/apr io functions, without doing any
buffering. On the Perl side everything comes down to PerlIO_write, whose proto:
Perl_PerlIO_write(pTHX_ PerlIO *f, const void *vbuf, Size_t count)
and Size_t < off_t.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Apr 04, 2004 at 09:51:38PM -0700, Stas Bekman wrote:
> Geoffrey Young wrote:
> >you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags
> >and perl recompiled, not that mod_perl can get away with simply not
> >including that value when it itself is compiled. if it were stripped only
> >in mod_perl compilation you would have conflicting definitions of off_t in
> >the two sources - long long in perl and int in mod_perl/APR.
>
> No Joe is talking about mod_perl only. It's not a problem to use perl and
> mod_perl mismatching as long as we don't interface apis which use off_t,
> like seek(). In which case we croak, just as before. The logic here didn't
> change.
Actually, I am surprised that mod_perl can get away with stripping
-D_F_O_B=64 from the Perl cflags, but it seems like it can.
If there are any places in the Perl C API where an Off_t is taken, Perl
will be passed a long when it was expecting a long long in this case: so
there are potential problems here.
Hmmm... looks like the PerlIOBuf structure has an Off_t in it, so using
that in mod_perl could be problematic. In general on x86 maybe you just
get away with the long vs long long mismatch in passed vs expected
function arguments/return values.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Joe Orton wrote:
>>The problem that mod_perl has to work around is when you take a package
>>built with approach (1), i.e. Perl, and any package which was *not*
>>built with (1), i.e. APR, and want to interface between them. [1]
>>
>>So what you want to know is whether APR was built using approach (1) or
>>not. APR_HAS_LARGE_FILES in HEAD just tells you whether APR was built
>>using approach (2) or not, which isn't useful in solving this problem.
>>
>>Does that make sense?
>
>
> yes, I think so. so. by this
>
>
>> if ($perl_lfs64 && !$apr_lfs64) {
>> # Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
>> }
>
>
> you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags
> and perl recompiled, not that mod_perl can get away with simply not
> including that value when it itself is compiled. if it were stripped only
> in mod_perl compilation you would have conflicting definitions of off_t in
> the two sources - long long in perl and int in mod_perl/APR.
No Joe is talking about mod_perl only. It's not a problem to use perl and
mod_perl mismatching as long as we don't interface apis which use off_t, like
seek(). In which case we croak, just as before. The logic here didn't change.
Of course you could recompile perl, but most users won't. I guess as 2.2 will
be released and users will move to it, the whole issue will go away, since apr
will have lfs enabled on the same platforms perl does.
>>This is why it is a really terribly silly idea to ever use
>>approach (1) in anything other than an entirely self-contained
>>application.
>
>
> hmm. I'm sure perl has a good reason for doing it that way, right? does
> anyone know? your explanation is clear and, if accurate, would seem to
> indicate that -D_FILE_OFFSET_BITS=64 might not be a good default for
> -Duselargefiles and we ought to bring this up to p5p?
Yes, if you can do it that would be great. I have started a way too many long
threads in the last few months.
FWIW, based on my previous questions about off_t, it seems that p5p lacks
expertise on that issue and simply follows the suite that someone started. So
I won't be surprised if we won't get an explanation of why perl does what it
does. But may be we will be lucky.
Your optimistic pessimist :)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> OK, let's do the background...
wow. thanks for all that. I never really groked the issue but you've
clarified it nicely. much appreciated!
> The problem that mod_perl has to work around is when you take a package
> built with approach (1), i.e. Perl, and any package which was *not*
> built with (1), i.e. APR, and want to interface between them. [1]
>
> So what you want to know is whether APR was built using approach (1) or
> not. APR_HAS_LARGE_FILES in HEAD just tells you whether APR was built
> using approach (2) or not, which isn't useful in solving this problem.
>
> Does that make sense?
yes, I think so. so. by this
> if ($perl_lfs64 && !$apr_lfs64) {
> # Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
> }
you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags
and perl recompiled, not that mod_perl can get away with simply not
including that value when it itself is compiled. if it were stripped only
in mod_perl compilation you would have conflicting definitions of off_t in
the two sources - long long in perl and int in mod_perl/APR.
sounds like a real bummer.
> This is why it is a really terribly silly idea to ever use
> approach (1) in anything other than an entirely self-contained
> application.
hmm. I'm sure perl has a good reason for doing it that way, right? does
anyone know? your explanation is clear and, if accurate, would seem to
indicate that -D_FILE_OFFSET_BITS=64 might not be a good default for
-Duselargefiles and we ought to bring this up to p5p?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> OK, let's do the background... on Unix systems where by default off_t is
> a "long", a 32-bit integer, there are two different ways to get "large
> file" support, i.e. the ability to manipulate files bigger than 2Gb:
Muchas Gracias, Joe. I've committed both your explanation and the logic which
now works fine with both, 2.0 and 2.1.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
OK, let's do the background... on Unix systems where by default off_t is
a "long", a 32-bit integer, there are two different ways to get "large
file" support, i.e. the ability to manipulate files bigger than 2Gb:
1) you compile using -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. This
makes sys/types.h expose off_t as a "long long", a 64-bit integer, and
changes the size of a few other types too. The C library headers
automatically arrange to expose a correct implementation of functions
like lseek() which take off_t parameters.
2) you compile using -D_LARGEFILE64_SOURCE, and use what is called the
"transitional" interface. This means that the system headers expose a
new type, "off64_t", which is a long long, but the size of off_t is not
changed. A bunch of new functions like lseek64() are exposed by the C
library headers, which take off64_t parameters in place of off_t.
Perl built with -Duselargefiles uses approach (1).
APR HEAD uses (2) by default. APR 0.9 does not by default use either
approach, but random users can take a httpd-2.0.49 tarball, and do:
export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
./configure
to build a copy of apr/httpd which uses approach (1), though this isn't
really a supported configuration.
The problem that mod_perl has to work around is when you take a package
built with approach (1), i.e. Perl, and any package which was *not*
built with (1), i.e. APR, and want to interface between them. [1]
So what you want to know is whether APR was built using approach (1) or
not. APR_HAS_LARGE_FILES in HEAD just tells you whether APR was built
using approach (2) or not, which isn't useful in solving this problem.
Does that make sense?
joe
[1]: In some cases, it may be OK to interface between packages which use
(1) and packages which use (2). APR HEAD is currently not such a case,
since the size of apr_ino_t is still changing when _FILE_OFFSET_BITS is
defined.
If you want to see how this matters, get some httpd function to do at
the very beginning of main():
printf("sizeof(request_rec) = %lu, sizeof(apr_finfo_t) = %ul",
sizeof(request_rec), sizeof(apr_finfo_t));
and then put the same printf in mod_perl somewhere, and see the
differences. This is why it is a really terribly silly idea to ever use
approach (1) in anything other than an entirely self-contained
application.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> if ($perl_lfs64 && !$apr_lfs64) {
> # Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
if I read your recent APR patch right, because APR uses lfs by default
on platforms that support it this is unlikely unless perl has made a big
mistake or APR has incorrectly detected lfs support?
> }
> elsif (!$perl_lfs64 && $apr_lfs64) {
> # Less serious conflict; this case isn't handled currently.
> # Don't strip anything from CFLAGS but still do the apr_file_seek
> # workaround, I think
compiling APR with --disable-lfs is also an option here, right?
> }
>
> Building APR in the manner to give the "less serious conflict" is really
> an unsupported configuration, and didn't work before httpd-2.0.49
> anyway, so it would be OK to just give an error on that extremely
> unlikely situation.
>
> This avoids needing to ever look at APR_HAS_LARGE_FILES, so should fix
> the issue with APR HEAD, and should work fine for 2.0.x too.
hmm. in trying to get my head around the issue I still don't see where I
was having the problem that launched the thread. my perl contains
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64, and APR_HAS_LARGE_FILES was 1
but things still weren't right. maybe it's because the only apxs option
that comes back for me is -D_LARGEFILE64_SOURCE and -D_FILE_OFFSET_BITS=64
is missing? does that hint that something in APR's new detection isn't
quite right?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
The concrete proposal:
1. mod_perl should be extracting the output of `apr-config --cflags`
`apr-config --cppflags` at some point. This can either be done by using
apr-config directly, or by getting it out of `apxs -q EXTRA_CFLAGS` and
`apxs -q EXTRA_CPPFLAGS`.
(apxs in 2.0 sucks really because `apxs -q CFLAGS` doesn't tell you
everything it should)
2. given this, has_large_files_conflict can *accurately* detect the
conflict situation, given $apxs_cflags which contains all the above
{EXTRA_CPP,EXTRA_C,C}_FLAGS variables, and $perl_cflags which is Perl's
$Config{ccflags}:
my $apr_lfs64 = 0, $perl_lfs64 = 0;
$apr_lfs64 = 1 if $apxs_cflags =~ /-D_FILE_OFFSET_BITS=64/;
$perl_lfs64 = 1 if $perl_cflags =~ /-D_FILE_OFFSET_BITS=64/;
if ($perl_lfs64 && !$apr_lfs64) {
# Serious Conflict! Strip -D_FILE_OFFSET_BITS=64 from $perl_cflags.
}
elsif (!$perl_lfs64 && $apr_lfs64) {
# Less serious conflict; this case isn't handled currently.
# Don't strip anything from CFLAGS but still do the apr_file_seek
# workaround, I think
}
Building APR in the manner to give the "less serious conflict" is really
an unsupported configuration, and didn't work before httpd-2.0.49
anyway, so it would be OK to just give an error on that extremely
unlikely situation.
This avoids needing to ever look at APR_HAS_LARGE_FILES, so should fix
the issue with APR HEAD, and should work fine for 2.0.x too.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Thu, Apr 01, 2004 at 02:49:56PM -0800, Stas Bekman wrote:
>
>>Joe Orton wrote:
>>
>>>I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
>>>0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
>>>just doesn't make sense.
>>>
>>>I think the right way to solve this is to make mod_perl's
>>>has_large_files_conflict/strip_lfs functions a bit more smarter, I'll
>>>follow up with a more concrete proposal tomorrow.
>>
>>I doubt this has anything to do with has_large_files_conflict. It's only
>>used to decide whether we can allow seek() with non-zero offset. The
>>segfaulting happens much much earlier.
>
>
> The primary reason for has_large_files_conflict/strip_lfs existing is to
> prevent the problem now being seen on HEAD happening with 2.0. Remove
> the strip_lfs logic from mod_perl and try building against a 2.0.x
> release and I'll bet you'll see exactly the same issue.
right, I forgot that we had that strip_lfs function, I thought it was
something from apr. So looking forward for your proposal/patch for the
improved strip_lfs, Joe!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Apr 01, 2004 at 02:49:56PM -0800, Stas Bekman wrote:
> Joe Orton wrote:
> >I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
> >0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
> >just doesn't make sense.
> >
> >I think the right way to solve this is to make mod_perl's
> >has_large_files_conflict/strip_lfs functions a bit more smarter, I'll
> >follow up with a more concrete proposal tomorrow.
>
> I doubt this has anything to do with has_large_files_conflict. It's only
> used to decide whether we can allow seek() with non-zero offset. The
> segfaulting happens much much earlier.
The primary reason for has_large_files_conflict/strip_lfs existing is to
prevent the problem now being seen on HEAD happening with 2.0. Remove
the strip_lfs logic from mod_perl and try building against a 2.0.x
release and I'll bet you'll see exactly the same issue.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
> 0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
> just doesn't make sense.
>
> I think the right way to solve this is to make mod_perl's
> has_large_files_conflict/strip_lfs functions a bit more smarter, I'll
> follow up with a more concrete proposal tomorrow.
I doubt this has anything to do with has_large_files_conflict. It's only used
to decide whether we can allow seek() with non-zero offset. The segfaulting
happens much much earlier.
> (well, actually, the Right Place to solve this is to get Perl to not do
> anything really silly like export -D_FILE_OFFSET_BITS=64 in the first
> place, but hey)
Why do you find that silly? If perl was built with these options, other apps
linking that library also need to build with this option. If not there will be
a mismatch in what perl and the app think about the size of several data types.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Joe Orton <jo...@redhat.com>.
I actually can't convince myself that changing APR_HAS_LARGE_FILES to be
0 on APR HEAD when LFS support is *enabled* is the right thing to do; it
just doesn't make sense.
I think the right way to solve this is to make mod_perl's
has_large_files_conflict/strip_lfs functions a bit more smarter, I'll
follow up with a more concrete proposal tomorrow.
(well, actually, the Right Place to solve this is to get Perl to not do
anything really silly like export -D_FILE_OFFSET_BITS=64 in the first
place, but hey)
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
>>Joe, regarding your change:
>>http://marc.theaimsgroup.com/?l=apr-cvs&m=108039307912906&w=2
>>which seems to completely hose mod_perl 2
>>
>>Are you sure this is a good step:
>>
>> +#if APR_HAS_LARGE_FILES
>> +#define lseek(f,o,w) lseek64(f,o,w)
>> +#define ftruncate(f,l) ftruncate64(f,l)
>> +#endif
>
>
> this is in an internal APR header, the changes are not exported to any
> users of APR, so it shouldn't matter.
Good then :) Thanks Joe for fixing the problem.
> In this case, mod_perl doesn't strip _FILE_OFFSET_BITS=64 from the Perl
> ccflags like normal. But _FILE_OFFSET_BITS=64 does still change the
> size of apr_ino_t and hence the size of apr_finfo_t and hence the
> offsets into request_rec.
It can't be stripped, because that's how perl was built and if stripped apps
linked with libperl.so (e.g. mod_perl) won't function properly.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Orton wrote:
> On Thu, Apr 01, 2004 at 09:09:22AM -0500, Geoffrey Young wrote:
>
>>as an aside, does it make sense to add something about LFS to the output of
>>httpd -V?
>
>
> Oooh, hmmm, dunno. Problem is that all that users probably want to know
> is whether "large" (>2gb) files are supported, and APR_HAS_LARGE_FILES
> doesn't necessarily tell you that.
oh, ok. I don't claim to know all the issues. I was just thinking that it
might be easier to track down conflicts if we could see that APR is using a
64bit implementation under the hood while some other library (like perl) is
not. or something like that - the differences are really beyond me, so the
kind of compatibility issues I'm thinking about might not even exist.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> so s/APR_HAS_LARGE_FILES 1/APR_HAS_LARGE_FILES 0/ on apr.h and the
> problem will go away. I'll fix APR.
yup, that seemed to do the trick. verified with both prefork and worker
without --disable-lfs.
as an aside, does it make sense to add something about LFS to the output of
httpd -V?
anyway, thanks for taking the time to work on it - much appreciated in our
little perl corner :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The worker backtrace is not for the thread which actually generated the
> SEGV; using "info threads" should show which one is different, then
> "thread <n>" and backtrace to switch to it in gdb, if you like.
ok, I'll try that.
>
> What is the repro case? Just build everything from HEAD and run the
> mod_perl test suite?
yup, philippe did exactly that and saw the same thing (for worker). if it
matters, we're both on fedora - I haven't tried another os. but doing the
known NPTL workarounds for fedora didn't seem to help and something is
affecting prefork as well.
>
> You have made completely fresh checkout and rebuilds of apr, apr-util,
> httpd, and mod_perl? Because the size of apr_off_t changed you can't
> mix and match any binaries between "HEAD from before LFS" with "HEAD
> after LFS was enabled".
yes, this is all httpd/apr/apr-util and mod_perl HEAD. I actually recompile
from them all from HEAD nightly (as well as the 2_0_BRANCH stuff).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Please show us the backtrace, Geoff.
>
>
> I've been staring at them all night but maybe they will make sense to you :)
> it's different on prefork and worker.
No, it doesn't :( I expected to see problems in the apr/apache io layers, but
you get it in totally different places.
Joe, regarding your change:
http://marc.theaimsgroup.com/?l=apr-cvs&m=108039307912906&w=2
which seems to completely hose mod_perl 2
Are you sure this is a good step:
+#if APR_HAS_LARGE_FILES
+#define lseek(f,o,w) lseek64(f,o,w)
+#define ftruncate(f,l) ftruncate64(f,l)
+#endif
this redefine affects any project that binds apr. Why not use a different
name, in order not to affect other code that you didn't write and which
doesn't expect lseek to be lseek64.
the same in other files you have changed in this commit. I'm shooting in the
dark here, guessing that this is the reason for the problems we are seeing.
> prefork:
>
> #0 0x08076165 in ap_get_module_config (cv=0x0, m=0xeb8820) at util_debug.c:105
> #1 0x00d692bb in modperl_hook_create_request (r=0x966c628) at mod_perl.c:613
> #2 0x080826b6 in ap_run_create_request (r=0x966c628) at request.c:79
> #3 0x08078e99 in ap_read_request (conn=0x96667a8) at protocol.c:841
> #4 0x0806007a in ap_process_http_connection (c=0x96667a8) at http_core.c:246
> #5 0x0807400e in ap_run_process_connection (c=0x96667a8) at connection.c:42
> #6 0x080743fd in ap_process_connection (c=0x96667a8, csd=0x9666610) at
> connection.c:175
> #7 0x080676c7 in child_main (child_num_arg=0) at prefork.c:624
> #8 0x08067862 in make_child (s=0x84d0e48, slot=0) at prefork.c:719
> #9 0x08067ac1 in perform_idle_server_maintenance (p=0x84cf0a8) at prefork.c:854
> #10 0x08067f37 in ap_mpm_run (_pconf=0x84cf0a8, plog=0x84f9150, s=0x84d0e48)
> at prefork.c:1057
> #11 0x0806ea1a in main (argc=9, argv=0xbff31dd4) at main.c:665
>
>
> worker:
>
> #0 0x008e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1 0x00b61b8b in __read_nocancel () from /lib/tls/libpthread.so.0
> #2 0x080e6326 in ap_mpm_pod_check (pod=0xaed5540) at pod.c:53
> #3 0x080e4490 in child_main (child_num_arg=0) at worker.c:1225
> #4 0x080e461e in make_child (s=0x9defcd8, slot=0) at worker.c:1308
> #5 0x080e46b6 in startup_children (number_to_start=1) at worker.c:1327
> #6 0x080e4e2a in ap_mpm_run (_pconf=0x9dea0a8, plog=0x9e341d0, s=0x9defcd8)
> at worker.c:1643
> #7 0x080ecb5e in main (argc=9, argv=0xfef20a44) at main.c:665
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> Please show us the backtrace, Geoff.
I've been staring at them all night but maybe they will make sense to you :)
it's different on prefork and worker.
prefork:
#0 0x08076165 in ap_get_module_config (cv=0x0, m=0xeb8820) at util_debug.c:105
#1 0x00d692bb in modperl_hook_create_request (r=0x966c628) at mod_perl.c:613
#2 0x080826b6 in ap_run_create_request (r=0x966c628) at request.c:79
#3 0x08078e99 in ap_read_request (conn=0x96667a8) at protocol.c:841
#4 0x0806007a in ap_process_http_connection (c=0x96667a8) at http_core.c:246
#5 0x0807400e in ap_run_process_connection (c=0x96667a8) at connection.c:42
#6 0x080743fd in ap_process_connection (c=0x96667a8, csd=0x9666610) at
connection.c:175
#7 0x080676c7 in child_main (child_num_arg=0) at prefork.c:624
#8 0x08067862 in make_child (s=0x84d0e48, slot=0) at prefork.c:719
#9 0x08067ac1 in perform_idle_server_maintenance (p=0x84cf0a8) at prefork.c:854
#10 0x08067f37 in ap_mpm_run (_pconf=0x84cf0a8, plog=0x84f9150, s=0x84d0e48)
at prefork.c:1057
#11 0x0806ea1a in main (argc=9, argv=0xbff31dd4) at main.c:665
worker:
#0 0x008e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00b61b8b in __read_nocancel () from /lib/tls/libpthread.so.0
#2 0x080e6326 in ap_mpm_pod_check (pod=0xaed5540) at pod.c:53
#3 0x080e4490 in child_main (child_num_arg=0) at worker.c:1225
#4 0x080e461e in make_child (s=0x9defcd8, slot=0) at worker.c:1308
#5 0x080e46b6 in startup_children (number_to_start=1) at worker.c:1327
#6 0x080e4e2a in ap_mpm_run (_pconf=0x9dea0a8, plog=0x9e341d0, s=0x9defcd8)
at worker.c:1643
#7 0x080ecb5e in main (argc=9, argv=0xfef20a44) at main.c:665
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: large file support
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi all
>
> I've traced the 2.1 issue reported on modperl@ (and seen by both philippe
> and I) down to this APR change:
>
> http://marc.theaimsgroup.com/?l=apr-cvs&m=108039307912906&w=2
>
> building Apache with --disable-lfs puts everything back to normal.
>
> now, I'm not sure whether the problem is with APR, or if all of a sudden the
> automagical intuition of off_t foo is interfering with some assumptions
> mod_perl makes. in either case, it's something that we need to resolve so
> we work with APR 1.0.
>
> ideas welcome.
Please show us the backtrace, Geoff.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org