Tom Caldwell wrote:
Stas and Marc,
So after a week hiatus I was finally able to return to my
Perl/ModPerl2/Apache2 woes on my Dell 64bit box running redhat linux.
When we last left the main saga, I had just rebuilt perl and modperl
with the -fPIC flag only to find that the tests for subprocess.t
Stas and Marc,
So after a week hiatus I was finally able to return to my
Perl/ModPerl2/Apache2 woes on my Dell 64bit box running redhat
linux.
When we last left the main saga, I had just rebuilt perl and
modperl with the -fPIC flag only to find that the tests for
subprocess.t would not work. I
Marc GrÃcia wrote:
El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va
escriure:
Marc GrÃcia wrote:
I had some problems like this on my new x86_64 machine with mod_perl2,
seems that not only perl must be compiled with -fPIC , also apache and
all libraries or modules you plan to use. I
El dc 04 de 05 del 2005 a les 10:09 -0500, en/na Tom Caldwell va escriure:
I have to concur with Marc - that there was no -fPIC and the
necessary libraries were missing as well on my x86_64 red hat box.
This seems to be happening with all the builds - perl, mod_perl,
and probably apache to
I have to concur with Marc - that there was no -fPIC and the
necessary libraries were missing as well on my x86_64 red hat box.
This seems to be happening with all the builds - perl, mod_perl,
and probably apache too. (I haven't had a chance to get back to
rebuilding apache as last suggested.)
El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va escriure:
Marc Gràcia wrote:
> I had some problems like this on my new x86_64 machine with mod_perl2,
> seems that not only perl must be compiled with -fPIC , also apache and
> all libraries or modules you plan to use. I think it
Tom Caldwell wrote:
is it possible that this path it not readable by user 'apache'? I doubt
so, since all other tests run just fine.
Well, the LD_LIBRARY_PATH gets set during the bash startup (.bashrc) so
if the test does > su - nobody- then the variable should be set.
so if you dump %ENV from
[CC'ing the list back]
Caldwell, Thomas S wrote:
I recompiled mod_perl but I did not recompile Apache2, if that is what is
meant by 'everything'.
Hmm, that's a good question. I think you need Apache2 too.
But they are distinct, right, so it shouldn't matter as long as Apache can
incorporate the l
Comments below.
On Sat, 2005-04-30 at 01:25, Stas Bekman wrote:
> Tom Caldwell wrote:
> > Stas,
> >
> > I forgot to mention that apache usually runs under a different account
> > than nobody (I use - apache), in case that matters.
>
> Of course. In which case you need to check 'apache' instead o
Marc Gràcia wrote:
I had some problems like this on my new x86_64 machine with mod_perl2,
seems that not only perl must be compiled with -fPIC , also apache and
all libraries or modules you plan to use. I think it's a general issue
with this architecture, not mod_perl related.
That's correct, Marc.
I had some problems like this on my new x86_64 machine with mod_perl2, seems that not only perl must be compiled with -fPIC , also apache and all libraries or modules you plan to use. I think it's a general issue with this architecture, not mod_perl related.
If not, there are runtime linking re
Tom Caldwell wrote:
Stas,
I forgot to mention that apache usually runs under a different account
than nobody (I use - apache), in case that matters.
Of course. In which case you need to check 'apache' instead of 'nobody'.
Also, I apologize for not cc'ing the list on the last message but I
normally
Stas,
I forgot to mention that apache usually runs under a different account
than nobody (I use - apache), in case that matters.
Also, I apologize for not cc'ing the list on the last message but I
normally use the mail client from my desktop machine instead of this
Ximian client on red hat and I
Tom Caldwell wrote:
So here are the reuslts of the versbose tests and the contents of
t/logs/error_log after running the failed tests.
[...]
# testing : testing subproc's stdin -> stderr + list context
# expected: my stderr
# received: /opt/perl/bin/perl: error while loading shared libraries:
libpe
So here are the reuslts of the versbose tests and the contents of
t/logs/error_log after running the failed tests.
t/TEST -verbose t/apache/subprocess.t
[warning] setting ulimit to allow core files
ulimit -c unlimited; /opt/perl/bin/perl
/opt/modperl/mod_perl-2.0.0-RC5/t/TEST -verbose 't/apache/s
[folks, please don't forget that all modperl issues are to be posted to
the list. Thank you.
CC'ing the list on this reply
]
Tom Caldwell wrote:
Stas,
I rebuilt perl to support dynamic libraries, as you suggested, and was
able to build mod_perl but now I am getting a failure when I run make
test.
Tom Caldwell wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
Modperl2 dynamic module build fails on Red Hat Linux (Intel 64)
with the following error.
gcc -shared \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo
modperl_log.lo modperl_config.lo
> -8<-- Start Bug Report 8<--
> 1. Problem Description:
>
> Modperl2 dynamic module build fails on Red Hat Linux (Intel 64)
> with the following error.
>
> gcc -shared \
> \
> mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo
> modperl_co
18 matches
Mail list logo
