Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)

2003-07-07 Thread Stas Bekman
[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)

2003-06-19 Thread jaco.greyling
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)

2003-06-19 Thread Ged Haywood
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)

2003-06-19 Thread jaco.greyling
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)

2003-06-18 Thread jaco.greyling
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)

2003-06-18 Thread Ged Haywood
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)

2003-06-18 Thread jaco.greyling
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)

2003-06-18 Thread Ged Haywood
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)

2003-06-18 Thread jaco.greyling
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)

2003-06-18 Thread Stas Bekman
[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)

2003-06-18 Thread jaco.greyling
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)

2003-06-17 Thread Stas Bekman
[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)

2003-06-17 Thread jaco.greyling
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.