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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
