Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: 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? Everything will work OK if all the components are compiled without large file support. Of course you won't be able to handle files > 2GB. 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"? mod_perl 1.x does it for you (i.e. uses perl's cppflags) if you build static (since it builds apache). perl -V:cppflags cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -I/usr/include/gdbm'; I'm not sure what happen if you build DSO. __ Stas BekmanJAm_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
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hey I found this link on the net and it seems to answer my question (right at the bottom), http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/uselargefiles_P3969/ Thanks to all who contributed to my query... Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 19 June 2003 14:45 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi there, On Thu, 19 Jun 2003 [EMAIL PROTECTED] wrote: > My question now is, did Doug take this into consideration when he > build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) I'm sure Doug took into consideration all sorts of things we never even thought about. Try it out and let us know what happens? > I think I need someone with 'inside information' into mod_perl Well you have the source code... :) 73, Ged. 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.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Thu, 19 Jun 2003 [EMAIL PROTECTED] wrote: > My question now is, did Doug take this into consideration when he > build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) I'm sure Doug took into consideration all sorts of things we never even thought about. Try it out and let us know what happens? > I think I need someone with 'inside information' into mod_perl Well you have the source code... :) 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Guys Everything you've said so far make complete sense (thanks for that!). My question now is, did Doug take this into consideration when he build mod_perl v1.27 (w/ PERL_USELARGEFILES=0) and somehow wrote a function that cleans up the data structures from perl? I think I need someone with 'inside information' into mod_perl to comment on this one... Thx again, Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 14:53 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: > As you can see it suggests rebuilding mod_perl with > $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged. 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.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi, mod_perl does not look different between 2 builds (lfs and non-lfs apache) - our assumption that mod_perl shares memory with Apache might just be wrong or there is a way for mod_perl to make system calls with lfs against perl and non-lfs against apache. Hence we need a developer feedback :) Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 14:53 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: > As you can see it suggests rebuilding mod_perl with > $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged. 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.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: > As you can see it suggests rebuilding mod_perl with > $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Ok -
This comes from the Makefile.PL:
sub uselargefiles_check {
return unless $] >= 5.006 and $Config{uselargefiles}
and $PERL_USELARGEFILES and $USE_APXS;
local $Apache::src::APXS = $WITH_APXS;
my $cflags = Apache::src->new->apxs('-q' => 'CFLAGS') || '';
return if $cflags =~ /LARGEFILE/;
$PERL_USELARGEFILES=0; #just do it since
return; #nobody seems to listen to the warning below
phat_warn(<mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 13:06
To: Greyling, Jaco
Cc: mod_perl Mailing List
Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there,
On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote:
> Thus without re-compiling my whole Perl 5.8.0 build I need to come
> up with a solution.
I really don't see why you don't recompile your Perl. It's not a big
deal and it's going to be a lot safer that way.
> 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.
I can't tell you how much what you're proposing to do worries me.
I wouldn't dream of doing it on one of my servers, not even on a
development machine.
The size of the files you access isn't the issue. It's the size of
the variables in the C data structures. If different parts of the
same code disagree about that, and they pass each other pointers to
different shaped structures, you are going to have serious problems.
As Stas said, the *best* you can hope for is an immediate crash of
some sort. It's possibile however that the problems might not surface
immediately and that the symptoms might not be obvious. You could
have all kinds of data corruption before you know what's hit you.
73,
Ged.
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.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: > Thus without re-compiling my whole Perl 5.8.0 build I need to come > up with a solution. I really don't see why you don't recompile your Perl. It's not a big deal and it's going to be a lot safer that way. > 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. I can't tell you how much what you're proposing to do worries me. I wouldn't dream of doing it on one of my servers, not even on a development machine. The size of the files you access isn't the issue. It's the size of the variables in the C data structures. If different parts of the same code disagree about that, and they pass each other pointers to different shaped structures, you are going to have serious problems. As Stas said, the *best* you can hope for is an immediate crash of some sort. It's possibile however that the problems might not surface immediately and that the symptoms might not be obvious. You could have all kinds of data corruption before you know what's hit you. 73, Ged.
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
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 BekmanJAm_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.
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 BekmanJAm_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
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
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? Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Regards, Jaco Greyling -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 03:36 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: > Guys, > > anyone with experience on the below problem??? why reposting the same question 3 times? Please give people some time to respond to your questions, you can't expect an immediate reply. > Please advice, I would really appreciate the help. [...] > Sorry if this question goes out to the wrong discussion group, but I've > been told if anyone could answer this then it'll be someone on this forum > :) Ok, here goes... Sounds like the right place to me. > We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with > LFS and Apache 1.3.27 (with LFS). > > To make a long story short...we are running into issues with vendors like > IBM and Oracle where they don't want to re-compile their code (i.e. > mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. > The only way (to our knowledge) we can do this is by re-compiling Perl > 5.8.0 without LFS, which means that we have to support two versions of Perl > / CPAN / etc...not likely in our current situation. Someone just told me > that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl > (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did > not support in earlier versions of mod_perl. > > BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about > Segmentation Faults (this is common when using LFS modules with a non-LFS > Apache build). For some reason we don't get these errors when using > mod_perl /LFS with non-LFS Apache. How is this possible? You have to send a complete problem report as explained here, including a core dump's back trace: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems > Here is our mod_perl build script: > > ... # run the following from the mod_perl source directory > $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ > USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... __ Stas BekmanJAm_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.
Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: > Guys, > > anyone with experience on the below problem??? why reposting the same question 3 times? Please give people some time to respond to your questions, you can't expect an immediate reply. > Please advice, I would really appreciate the help. [...] > Sorry if this question goes out to the wrong discussion group, but I've > been told if anyone could answer this then it'll be someone on this forum > :) Ok, here goes... Sounds like the right place to me. > We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with > LFS and Apache 1.3.27 (with LFS). > > To make a long story short...we are running into issues with vendors like > IBM and Oracle where they don't want to re-compile their code (i.e. > mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. > The only way (to our knowledge) we can do this is by re-compiling Perl > 5.8.0 without LFS, which means that we have to support two versions of Perl > / CPAN / etc...not likely in our current situation. Someone just told me > that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl > (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did > not support in earlier versions of mod_perl. > > BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about > Segmentation Faults (this is common when using LFS modules with a non-LFS > Apache build). For some reason we don't get these errors when using > mod_perl /LFS with non-LFS Apache. How is this possible? You have to send a complete problem report as explained here, including a core dump's back trace: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems > Here is our mod_perl build script: > > ... # run the following from the mod_perl source directory > $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ > USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... __ Stas BekmanJAm_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
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Guys, anyone with experience on the below problem??? Please advice, I would really appreciate the help. Regards, Jaco Greyling -Original Message- From: Greyling, Jaco Sent: 17 June 2003 10:14 To: [EMAIL PROTECTED] Subject: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) All Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... Regards, Jaco Greyling 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.
