Thanks for your prompt response! We did compile Apache with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" but we're trying to move away from this now, because of vendors like IBM and Oracle not willing to re-compile (websphere mods and mod_ossos) with the same flags. Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution.
Like I said before Doug MacEachern actually allows you to get away with this in mod_perl 1.27 (with mod_perl 1.24 it would squeal and terminate during compile time). Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. Is there another low level consideration I'm not taking into account? Last but not least...Perl 5.6.1 and greater compiles with LFS (default) and Apache has always compiled without it (unless you specifically specify it). Did you re-compile Apache with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"? Thanks again, Jaco Greyling -----Original Message----- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 10:59 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) [EMAIL PROTECTED] wrote: > Hey > > Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went > through successfully the 1st time)... > > Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to > run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but > I'm not sure what the outcome will be if I deploy this solution into our > production environment. Intermittent Segmentation Faults? Ah sorry then, I thought "I'm concerned about Segmentation Faults" meant that you had such. You can rebuild Apache with: CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64". Assuming that you don't trip on any functions that Apache considers unsafe on your os with largefiles enabled. See Makefile.PL for more info. The point is: You need to have both components to agree on sizeof() the vars they use. If they don't at best you will get immediate problem, at worst there will be subtle problems happening only in certain situations. It may work OK, if you call only methods which use variables, whose sizeof() doesn't change when LARGE_FILES are enabled. I know it's a big pain :( Same in mod_perl 2.0 and Apache 2.0. e.g. we have a problem with APR::PerlIO, and it seems that I've worked around it, by disabling "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" only for building this module, if perl was built with large files support. Your safest bet is to have both components compiled with the same large file flags. > Again...sorry for the 'impatience' but I need to make a decision today if > we're to go ahead with this solution... Understood. __________________________________________________________________ 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 Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
