You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tom Caldwell <to...@vanderbilt.edu> on 2005/04/27 18:35:27 UTC
[mp2] modperl2 compile error
> -------------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 modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_apache_compat.lo modperl_error.lo modperl_debug.lo modperl_common_util.lo modperl_common_log.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo modperl_exports.lo -Wl,-E /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a -L/opt/perl/lib/5.8.6/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lc \
> -o mod_perl.so
> /usr/bin/ld: /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoader.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
> /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[1]: *** [mod_perl.so] Error 1
> make[1]: Leaving directory `/opt/modperl/mod_perl-2.0.0-RC5/src/modules/perl'
> make: *** [modperl_lib] Error 2
>
> As I am running red hat, there is another version of Perl installed,
> apache2 has been built with the new version in /opt/perl.
>
> Any ideas?
>
> Thanks,
>
> Tom
>
> 2. Used Components and their Configuration:
>
> *** mod_perl version 1.999022
>
> *** using /opt/modperl/mod_perl-2.0.0-RC5/lib/Apache2/BuildConfig.pm
>
> *** Makefile.PL options:
> MP_APR_LIB => aprext
> MP_AP_PREFIX => /opt/apache2/server
> MP_COMPAT_1X => 1
> MP_GENERATE_XS => 1
> MP_LIBNAME => mod_perl
> MP_USE_DSO => 1
>
>
> *** The httpd binary was not found
> tc - found at /opt/apache2/server/bin/httpd
>
> *** (apr|apu)-config linking info
>
> -L/opt/apache2/server/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl
> -L/opt/apache2/server/lib -laprutil-0 -lgdbm -ldb-4.1 -lexpat
>
>
>
> *** /opt/perl/bin/perl -V
> Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
> Platform:
> osname=linux, osvers=2.4.21-27.0.2.el, archname=x86_64-linux
> uname='linux dizzy 2.4.21-27.0.2.el #1 smp wed jan 12 23:25:36 est 2005 x86_64
> x86_64 x86_64 gnulinux '
> config_args='-Dprefix=/opt/perl -Dcc=gcc'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
> useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=define use64bitall=define uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
> optimize='-O2',
> cppflags='-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
> ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-49)', gccosandvers=''
> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='gcc', ldflags =''
> libpth=/lib /usr/lib /usr/lib64
> libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
> perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
> libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
> gnulibc_version='2.3.2'
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> cccdlflags='-fpic', lddlflags='-shared'
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES
> Built under linux
> Compiled at Apr 25 2005 12:34:43
> %ENV:
> PERL_LWP_USE_HTTP_10="1"
> @INC:
> /opt/perl/lib/5.8.6/x86_64-linux
> /opt/perl/lib/5.8.6
> /opt/perl/lib/site_perl/5.8.6/x86_64-linux
> /opt/perl/lib/site_perl/5.8.6
> /opt/perl/lib/site_perl
> /opt/apache/perl
> .
>
> *** Packages of interest status:
>
> Apache2 : -
> Apache2::Request: -
> CGI : 3.05
> LWP : -
> mod_perl : -
> mod_perl2 : -
>
>
> 3. This is the core dump trace: (if you get a core dump):
>
> [CORE TRACE COMES HERE]
>
> This report was generated by t/REPORT on Wed Apr 27 16:01:59 2005 GMT.
>
> -------------8<---------- End Bug Report --------------8<----------
>
Re: [mp2] modperl2 compile error
Posted by Marc Gràcia <mg...@oasyssoft.com>.
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 too.
Ok,
If Perl is configured OK, mod_perl gets the args from Perl and
everytning goes well, the same on all normal Makefile.PL building
modules.
But you must take care that the rests of things you had to use are
compiled also with -fPIC.
All RedHat or Fedora default builds seems to have been compiled that
way, so no problems for default libs.
> (I haven't had a chance to get back to
> rebuilding apache as last suggested.) Different from Marc, I have
> been working as root, but still experiencing the same problems.
>
> The other thing I noticed was that a random directory (from the src
> tree) was added to the CCDLFLAGS when I added '-rdynamic -W1'
> during configure (as per the rpm version of perl). I had to remove
> this manually from the Makefile.
>
> Tom
>
> --On Wednesday, May 04, 2005 12:09 PM +0200 Marc Gràcia
> <mg...@oasyssoft.com> 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
> >> think it's a general issue with this architecture, not mod_perl
> >> related.
> >
> > That's correct, Marc.
> >
> >> If not, there are runtime linking relocation errors everywhere..
> >> (I also had to recompile with -fPIC db and libz, for example)
> >> Maybe that's the problem...
> >
> > I supposed that Tom has recompiled everything after rebuilding
> > perl.
> > mod_perl will pick up -fPIC automatically at compile time, if
> > perl was
> > compiled with it.
> >
> >
> > Yes that's Ok for all perl modules.
> > But BTW, my Perl Compilation did not put automaticaly the -fPIC
> > flag when configuring and also didn't detect the needed libraries
> > (The line when Config script lets you add additional libraries
> > was empty except for the ones i compiled for myself, see below).
> > I had to put all that manually (After a lot of recompilations
> > trying to find what was happening)
> >
> > I was using a closed environment in a user with no root
> > permissions. All dependencies except most basic ones
> > (libc,lpthreads,etc..) are compiled and self contained in the
> > user's home (I'm doing a untar-and-forget instalation for our
> > product).
> > The same procedure went OK on all other kind of machines... so
> > maybe perl Config has some problem with x86_64.
> > The base system was a Fedora Core 3 EM64T version with no 32bits
> > compatibility packages installed.
> > But everything is running OK after all, only the Configure script
> > failed..
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > Marc Gràcia <mg...@oasyssoft.com>
>
>
>
>
> Tom Caldwell
> Vanderbilt University Medical Center
>
>
Re: [mp2] modperl2 compile error
Posted by Tom Caldwell <to...@vanderbilt.edu>.
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.) Different from Marc, I have
been working as root, but still experiencing the same problems.
The other thing I noticed was that a random directory (from the src
tree) was added to the CCDLFLAGS when I added '-rdynamic -W1'
during configure (as per the rpm version of perl). I had to remove
this manually from the Makefile.
Tom
--On Wednesday, May 04, 2005 12:09 PM +0200 Marc Gràcia
<mg...@oasyssoft.com> 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
>> think it's a general issue with this architecture, not mod_perl
>> related.
>
> That's correct, Marc.
>
>> If not, there are runtime linking relocation errors everywhere..
>> (I also had to recompile with -fPIC db and libz, for example)
>> Maybe that's the problem...
>
> I supposed that Tom has recompiled everything after rebuilding
> perl.
> mod_perl will pick up -fPIC automatically at compile time, if
> perl was
> compiled with it.
>
>
> Yes that's Ok for all perl modules.
> But BTW, my Perl Compilation did not put automaticaly the -fPIC
> flag when configuring and also didn't detect the needed libraries
> (The line when Config script lets you add additional libraries
> was empty except for the ones i compiled for myself, see below).
> I had to put all that manually (After a lot of recompilations
> trying to find what was happening)
>
> I was using a closed environment in a user with no root
> permissions. All dependencies except most basic ones
> (libc,lpthreads,etc..) are compiled and self contained in the
> user's home (I'm doing a untar-and-forget instalation for our
> product).
> The same procedure went OK on all other kind of machines... so
> maybe perl Config has some problem with x86_64.
> The base system was a Fedora Core 3 EM64T version with no 32bits
> compatibility packages installed.
> But everything is running OK after all, only the Configure script
> failed..
>
>
>
>
>
>
>
>
> --
> Marc Gràcia <mg...@oasyssoft.com>
Tom Caldwell
Vanderbilt University Medical Center
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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 would
> not work. I tried several suggestions from Stas but nothing worked. Mark
> suggested recompiling apache as well and that was to be my next step
> before I was sidelined by other issues.
>
> When I rebuilt apache today, the modperl tests still failed at
> subprocess.t even after another modperl rebuild. So I did another
> reinstall of perl. This time during the configure operation when the
> script prompted for directories to search for standard libs the defaults
> were /usr/local/lib /lib /usr/lib (as before). After checking out the
> original redhat installed version of perl (from rpm vesion 5.8.0), I
> noticed that it used mostly libs from /lib64 and /usr/lib64. So I
> overrode the defaults for this question with - /lib /usr/lib /lib64
> /usr/lib64. Then when I got to the prompt for default libs it had all
> the ones I needed as the default value which it had failed to do before.
> I still had to change the link flags from -fpic to -fPIC and replace the
> default link switches with values I found in the redhat perl, but then
> all of the tests for perl and modperl passed.
>
> I did not even have to rebuild apache after that.
Great. Tom any chance you could write a simple step by step document of
what you have done, including commands for other users who will hit the
same problem? we can add it to the troubleshooting docs. Thanks!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Tom Caldwell <to...@vanderbilt.edu>.
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 tried several suggestions from Stas
but nothing worked. Mark suggested recompiling apache as well and
that was to be my next step before I was sidelined by other issues.
When I rebuilt apache today, the modperl tests still failed at
subprocess.t even after another modperl rebuild. So I did another
reinstall of perl. This time during the configure operation when
the script prompted for directories to search for standard libs the
defaults were /usr/local/lib /lib /usr/lib (as before). After
checking out the original redhat installed version of perl (from
rpm vesion 5.8.0), I noticed that it used mostly libs from /lib64
and /usr/lib64. So I overrode the defaults for this question with -
/lib /usr/lib /lib64 /usr/lib64. Then when I got to the prompt for
default libs it had all the ones I needed as the default value
which it had failed to do before. I still had to change the link
flags from -fpic to -fPIC and replace the default link switches
with values I found in the redhat perl, but then all of the tests
for perl and modperl passed.
I did not even have to rebuild apache after that.
So, thanks for all your help,
Tom
--On Thursday, May 05, 2005 10:23 PM -0700 Stas Bekman
<st...@stason.org> wrote:
> 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 think it's a general issue with this architecture, not
>>>> mod_perl related.
>>>
>>> That's correct, Marc.
>>>
>>>
>>>> If not, there are runtime linking relocation errors
>>>> everywhere.. (I also had to recompile with -fPIC db and libz,
>>>> for example) Maybe that's the problem...
>>>
>>> I supposed that Tom has recompiled everything after rebuilding
>>> perl. mod_perl will pick up -fPIC automatically at compile
>>> time, if perl was compiled with it.
>>
>>
>> Yes that's Ok for all perl modules.
>> But BTW, my Perl Compilation did not put automaticaly the -fPIC
>> flag when configuring and also didn't detect the needed
>> libraries (The line when Config script lets you add additional
>> libraries was empty except for the ones i compiled for myself,
>> see below).
>> I had to put all that manually (After a lot of recompilations
>> trying to find what was happening)
>>
>> I was using a closed environment in a user with no root
>> permissions. All dependencies except most basic ones
>> (libc,lpthreads,etc..) are compiled and self contained in the
>> user's home (I'm doing a untar-and-forget instalation for our
>> product).
>> The same procedure went OK on all other kind of machines... so
>> maybe perl Config has some problem with x86_64.
>> The base system was a Fedora Core 3 EM64T version with no 32bits
>> compatibility packages installed.
>> But everything is running OK after all, only the Configure script
>> failed..
>
> Marc, you may want to ask perl5-porters to help you with this
> issue. As you have figured out, mod_perl just picks perl's flags,
> so it's a perl issue.
>
> --
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
Tom Caldwell
Vanderbilt University Medical Center
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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 think it's a general issue
>>>with this architecture, not mod_perl related.
>>
>>That's correct, Marc.
>>
>>
>>>If not, there are runtime linking relocation errors everywhere.. (I also
>>>had to recompile with -fPIC db and libz, for example)
>>>Maybe that's the problem...
>>
>>I supposed that Tom has recompiled everything after rebuilding perl.
>>mod_perl will pick up -fPIC automatically at compile time, if perl was
>>compiled with it.
>
>
> Yes that's Ok for all perl modules.
> But BTW, my Perl Compilation did not put automaticaly the -fPIC flag
> when configuring and also didn't detect the needed libraries (The line
> when Config script lets you add additional libraries was empty except
> for the ones i compiled for myself, see below).
> I had to put all that manually (After a lot of recompilations trying to
> find what was happening)
>
> I was using a closed environment in a user with no root permissions. All
> dependencies except most basic ones (libc,lpthreads,etc..) are compiled
> and self contained in the user's home (I'm doing a untar-and-forget
> instalation for our product).
> The same procedure went OK on all other kind of machines... so maybe
> perl Config has some problem with x86_64.
> The base system was a Fedora Core 3 EM64T version with no 32bits
> compatibility packages installed.
> But everything is running OK after all, only the Configure script
> failed..
Marc, you may want to ask perl5-porters to help you with this issue. As
you have figured out, mod_perl just picks perl's flags, so it's a perl issue.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Marc Gràcia <mg...@oasyssoft.com>.
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's a general issue
> > with this architecture, not mod_perl related.
>
> That's correct, Marc.
>
> > If not, there are runtime linking relocation errors everywhere.. (I also
> > had to recompile with -fPIC db and libz, for example)
> > Maybe that's the problem...
>
> I supposed that Tom has recompiled everything after rebuilding perl.
> mod_perl will pick up -fPIC automatically at compile time, if perl was
> compiled with it.
Yes that's Ok for all perl modules.
But BTW, my Perl Compilation did not put automaticaly the -fPIC flag
when configuring and also didn't detect the needed libraries (The line
when Config script lets you add additional libraries was empty except
for the ones i compiled for myself, see below).
I had to put all that manually (After a lot of recompilations trying to
find what was happening)
I was using a closed environment in a user with no root permissions. All
dependencies except most basic ones (libc,lpthreads,etc..) are compiled
and self contained in the user's home (I'm doing a untar-and-forget
instalation for our product).
The same procedure went OK on all other kind of machines... so maybe
perl Config has some problem with x86_64.
The base system was a Fedora Core 3 EM64T version with no 32bits
compatibility packages installed.
But everything is running OK after all, only the Configure script
failed..
>
--
Marc Gràcia <mg...@oasyssoft.com>
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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.
> If not, there are runtime linking relocation errors everywhere.. (I also
> had to recompile with -fPIC db and libz, for example)
> Maybe that's the problem...
I supposed that Tom has recompiled everything after rebuilding perl.
mod_perl will pick up -fPIC automatically at compile time, if perl was
compiled with it.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Marc Gràcia <mg...@oasyssoft.com>.
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 relocation errors everywhere.. (I also
had to recompile with -fPIC db and libz, for example)
Maybe that's the problem...
El dv 29 de 04 del 2005 a les 23:25 -0700, en/na Stas Bekman va
escriure:
> 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 use the mail client from my desktop machine instead of this
> > Ximian client on red hat and I am not used to the client not doing the
> > cc for me.
>
> No worries.
>
> > Yes, I noticed that nobody was having trouble finding libperl.so, but it
> > seemed very strange that none of the other tests failed.
> >
> > Anyway, I tried to
> > su - nobody
> > which failed because the shell was set to /sbin/nologin.
>
> su - apache
>
> > So I fixed that (set shell to bash) and set the .bashrc file to set the
> > LD_LIBRARY_PATH to
> > /opt/perl/lib/5.8.6/x86_64-linux/CORE:/opt/apache2/server/lib/:/usr/lib64
> > so it can find libperl.so
> > /opt/perl/bin/perl -V then ran correctly from the nobody account.
> >
> > Then I reran the tests and got the same failures here is the test report
> > (see below).
> >
> > Also, I was able to run the 4 scripts in t/htdocs/util - argv.pl
> > env.pl in_err.pl in_out.pl
> >
> > They seemed to work fine except env.pl did not print anything.
> >
> > Thanks for looking into this,
> >
> > Tom
> >
> > P.S. Here is the other info you asked for.
> >
> > First line of t/TEST is
> > #!/opt/perl/bin/perl
> >
> > ldd /opt/perl/bin/perl
> > libperl.so => /opt/perl/lib/5.8.6/x86_64-linux/CORE/libperl.so
> > (0x0000002a9566d000)
>
> is it possible that this path it not readable by user 'apache'? I doubt
> so, since all other tests run just fine.
>
> what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be:
>
> #!/bin/sh
>
> printenv > /tmp/dump
> ldd /opt/perl/bin/perl >> /tmp/dump
>
> and run the subprocess test? This will show what the environment this
> subprocess script is running under.
>
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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 your modperl handler, is it there?
>>what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be:
>
> ( I take it you mean t/htdocs/util/argv.pl ?)
yes, sorry
> But these scripts aren't run during the test sequence. The tests that
> are failing are coming out of t/response/TestApache/subprocess.pm (as
> per t/logs/error_log) unless I'm missing something?
>
> I use >t/TEST -verbose t/apache/subprocess.t - as per
> http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
> 'make test' Failures - to run the tests that are failing.
t/apache/subprocess.t is the client part.
t/response/TestApache/subprocess.pm is the server part. So they do get run
during this test.
> Is there another way to perform the tests so that the scripts in
> t/htdocs/util are run instead?
please see above.
Notice though that those scripts are autogenerated when you run
't/TEST -conf' or 'make test', but once you run those you can change the
scripts and following with just t/TEST won't touch them.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Tom Caldwell <to...@vanderbilt.edu>.
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 of 'nobody'.
>
> > 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 am not used to the client not doing the
> > cc for me.
>
> No worries.
>
> > Yes, I noticed that nobody was having trouble finding libperl.so, but it
> > seemed very strange that none of the other tests failed.
> >
> > Anyway, I tried to
> > su - nobody
> > which failed because the shell was set to /sbin/nologin.
>
> su - apache
>
> > So I fixed that (set shell to bash) and set the .bashrc file to set the
> > LD_LIBRARY_PATH to
> > /opt/perl/lib/5.8.6/x86_64-linux/CORE:/opt/apache2/server/lib/:/usr/lib64
> > so it can find libperl.so
> > /opt/perl/bin/perl -V then ran correctly from the nobody account.
> >
> > Then I reran the tests and got the same failures here is the test report
> > (see below).
> >
> > Also, I was able to run the 4 scripts in t/htdocs/util - argv.pl
> > env.pl in_err.pl in_out.pl
> >
> > They seemed to work fine except env.pl did not print anything.
> >
> > Thanks for looking into this,
> >
> > Tom
> >
> > P.S. Here is the other info you asked for.
> >
> > First line of t/TEST is
> > #!/opt/perl/bin/perl
> >
> > ldd /opt/perl/bin/perl
> > libperl.so => /opt/perl/lib/5.8.6/x86_64-linux/CORE/libperl.so
> > (0x0000002a9566d000)
> 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.
>
> what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be:
( I take it you mean t/htdocs/util/argv.pl ?)
But these scripts aren't run during the test sequence. The tests that
are failing are coming out of t/response/TestApache/subprocess.pm (as
per t/logs/error_log) unless I'm missing something?
I use >t/TEST -verbose t/apache/subprocess.t - as per
http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
'make test' Failures - to run the tests that are failing.
Is there another way to perform the tests so that the scripts in
t/htdocs/util are run instead?
Thanks,
Tom
>
> #!/bin/sh
>
> printenv > /tmp/dump
> ldd /opt/perl/bin/perl >> /tmp/dump
>
> and run the subprocess test? This will show what the environment this
> subprocess script is running under.
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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 use the mail client from my desktop machine instead of this
> Ximian client on red hat and I am not used to the client not doing the
> cc for me.
No worries.
> Yes, I noticed that nobody was having trouble finding libperl.so, but it
> seemed very strange that none of the other tests failed.
>
> Anyway, I tried to
> su - nobody
> which failed because the shell was set to /sbin/nologin.
su - apache
> So I fixed that (set shell to bash) and set the .bashrc file to set the
> LD_LIBRARY_PATH to
> /opt/perl/lib/5.8.6/x86_64-linux/CORE:/opt/apache2/server/lib/:/usr/lib64
> so it can find libperl.so
> /opt/perl/bin/perl -V then ran correctly from the nobody account.
>
> Then I reran the tests and got the same failures here is the test report
> (see below).
>
> Also, I was able to run the 4 scripts in t/htdocs/util - argv.pl
> env.pl in_err.pl in_out.pl
>
> They seemed to work fine except env.pl did not print anything.
>
> Thanks for looking into this,
>
> Tom
>
> P.S. Here is the other info you asked for.
>
> First line of t/TEST is
> #!/opt/perl/bin/perl
>
> ldd /opt/perl/bin/perl
> libperl.so => /opt/perl/lib/5.8.6/x86_64-linux/CORE/libperl.so
> (0x0000002a9566d000)
is it possible that this path it not readable by user 'apache'? I doubt
so, since all other tests run just fine.
what if you change one of these scripts (.e.g. t/htdocs/argv.pl) to be:
#!/bin/sh
printenv > /tmp/dump
ldd /opt/perl/bin/perl >> /tmp/dump
and run the subprocess test? This will show what the environment this
subprocess script is running under.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Tom Caldwell <to...@vanderbilt.edu>.
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 am not used to the client not doing the
cc for me.
Thanks,
Tom
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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:
> libperl.so: cannot open shared object file: No such file or directory
> not ok 5
excellent. So it fails to run the scripts located in t/htdocs/util/. Can
you run those from the command line? It looks like /opt/perl/bin/perl
can't find libperl.so when run as 'nobody'. Try:
su
su - nobody
/opt/perl/bin/perl -V
Do you have some special env vars that tell perl where to find libperl.so?
check the output of 'printenv' in your shell.
BTW, what's the first line of t/TEST?
Finally, please post the output of:
ldd /opt/perl/bin/perl
thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Tom Caldwell <to...@vanderbilt.edu>.
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/subprocess.t'
[warning] root mode: changing the files ownership to 'nobody' (99:99)
[warning] testing whether 'nobody' is able to -rwx
/opt/modperl/mod_perl-2.0.0-RC5/t
"/opt/perl/bin/perl"
-Mlib=/opt/modperl/mod_perl-2.0.0-RC5/Apache-Test/lib -MApache::TestRun
-e 'eval { Apache::TestRun::run_root_fs_test(99, 99,
q[/opt/modperl/mod_perl-2.0.0-RC5/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/opt/apache2/server/bin/httpd -d /opt/modperl/mod_perl-2.0.0-RC5/t -f
/opt/modperl/mod_perl-2.0.0-RC5/t/conf/httpd.conf -D APACHE2
using Apache/2.0.54 (prefork MPM)
waiting 120 seconds for server to start: .[Thu Apr 28 14:26:44 2005]
[info] 6 Apache2:: modules loaded
[Thu Apr 28 14:26:44 2005] [info] 0 APR:: modules loaded
[Thu Apr 28 14:26:44 2005] [info] base server + 27 vhosts ready to run
tests
.
waiting 120 seconds for server to start: ok (waited 1 secs)
server localhost.localdomain:8529 started
server localhost.localdomain:8530 listening (filter_out_apache)
server localhost.localdomain:8531 listening (TestModules::proxy)
server localhost.localdomain:8532 listening (TestModperl::merge)
server localhost.localdomain:8533 listening (TestModperl::perl_options)
server localhost.localdomain:8534 listening (TestModperl::setupenv)
server localhost.localdomain:8535 listening (TestUser::rewrite)
server localhost.localdomain:8536 listening (TestVhost::log)
server localhost.localdomain:8537 listening (TestVhost::config)
server localhost.localdomain:8538 listening (TestProtocol::pseudo_http)
server localhost.localdomain:8539 listening (TestProtocol::echo_bbs)
server localhost.localdomain:8540 listening (TestProtocol::echo_filter)
server localhost.localdomain:8541 listening (TestProtocol::echo_bbs2)
server localhost.localdomain:8542 listening (TestProtocol::echo_timeout)
server localhost.localdomain:8543 listening (TestProtocol::echo_block)
server localhost.localdomain:8544 listening
(TestProtocol::echo_nonblock)
server localhost.localdomain:8545 listening (TestPreConnection::note)
server localhost.localdomain:8546 listening (TestHooks::hookrun)
server localhost.localdomain:8547 listening (TestHooks::init)
server localhost.localdomain:8548 listening (TestHooks::trans)
server localhost.localdomain:8549 listening
(TestHooks::stacked_handlers2)
server localhost.localdomain:8550 listening (TestHooks::startup)
server localhost.localdomain:8551 listening
(TestFilter::in_bbs_inject_header)
server localhost.localdomain:8552 listening (TestFilter::in_str_msg)
server localhost.localdomain:8553 listening
(TestFilter::both_str_con_add)
server localhost.localdomain:8554 listening (TestFilter::in_bbs_msg)
server localhost.localdomain:8555 listening (TestDirective::perlmodule)
server localhost.localdomain:8556 listening (TestDirective::perlrequire)
server localhost.localdomain:8557 listening
(TestDirective::perlloadmodule4)
server localhost.localdomain:8558 listening
(TestDirective::perlloadmodule5)
server localhost.localdomain:8559 listening
(TestDirective::perlloadmodule3)
server localhost.localdomain:8560 listening
(TestDirective::perlloadmodule6)
server localhost.localdomain:8561 listening
(TestHooks::push_handlers_anon)
t/apache/subprocess....1..5
# Running under perl version 5.008006 for linux
# Current time local: Thu Apr 28 14:26:44 2005
# Current time GMT: Thu Apr 28 19:26:44 2005
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.22
ok 1
# testing : passing ARGV
# expected: [
# foo,
# bar,
# ]
# received: [
# ]
not ok 2
# testing : passing env via subprocess_env
# expected: my cool proc
# received:
not ok 3
# testing : testing subproc's stdin -> stdout + list context
# expected: my cool proc
# received:
not ok 4
# testing : testing subproc's stdin -> stderr + list context
# expected: my stderr
# received: /opt/perl/bin/perl: error while loading shared libraries:
libperl.so: cannot open shared object file: No such file or directory
not ok 5
FAILED tests 2-5
Failed 4/5 tests, 20.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/apache/subprocess.t 5 4 80.00% 2-5
Failed 1/1 test scripts, 0.00% okay. 4/5 subtests failed, 20.00% okay.
[warning] server localhost.localdomain:8529 shutdown
[ error] error running tests (please examine t/logs/error_log)
dizzy:root# more t/logs/error_log
[Thu Apr 28 14:26:44 2005] [info] Init: Initializing OpenSSL library
[Thu Apr 28 14:26:44 2005] [info] Init: Seeding PRNG with 0 bytes of
entropy
[Thu Apr 28 14:26:44 2005] [info] Init: Generating temporary RSA private
keys (512/1024 bits)
[Thu Apr 28 14:26:44 2005] [info] Init: Generating temporary DH
parameters (512/1024 bits)
[Thu Apr 28 14:26:44 2005] [warn] Init: Session Cache is not configured
[hint: SSLSessionCache]
[Thu Apr 28 14:26:44 2005] [info] Init: Initializing (virtual) servers
for SSL
[Thu Apr 28 14:26:44 2005] [info] Server: Apache/2.0.54, Interface:
mod_ssl/2.0.54, Library: OpenSSL/0.9.7a
END in modperl_extra.pl, pid=30577
[Thu Apr 28 14:26:45 2005] [notice] Digest: generating secret for digest
authentication ...
[Thu Apr 28 14:26:45 2005] [notice] Digest: done
[Thu Apr 28 14:26:45 2005] [info] Init: Initializing OpenSSL library
[Thu Apr 28 14:26:45 2005] [info] Init: Seeding PRNG with 0 bytes of
entropy
[Thu Apr 28 14:26:45 2005] [info] Init: Generating temporary RSA private
keys (512/1024 bits)
[Thu Apr 28 14:26:45 2005] [info] Init: Generating temporary DH
parameters (512/1024 bits)
[Thu Apr 28 14:26:45 2005] [info] Init: Initializing (virtual) servers
for SSL
[Thu Apr 28 14:26:45 2005] [info] Server: Apache/2.0.54, Interface:
mod_ssl/2.0.54, Library: OpenSSL/0.9.7a
[Thu Apr 28 14:26:45 2005] [notice] Apache/2.0.54 (Unix) world
domination series/2.0 mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2
mod_perl/1.999.22 Perl/v5.8.6 configured -- resuming normal operations
[Thu Apr 28 14:26:45 2005] [info] Server built: Apr 25 2005 15:47:46
[Thu Apr 28 14:26:45 2005] [debug] prefork.c(956): AcceptMutex: sysvsem
(default:
sysvsem)
# Failed test 2 in
/opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
line 66
# Failed test 3 in
/opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
line 79
# Failed test 4 in
/opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
line 93
# Failed test 5 in
/opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
line 107
[Thu Apr 28 14:26:46 2005] [info] Child process pid=30585 is exiting
[Thu Apr 28 14:26:46 2005] [info] Child process pid=30585 is exiting -
server pushEND in modperl_extra.pl, pid=30585
[Thu Apr 28 14:26:46 2005] [info] Child process pid=30586 is exiting
[Thu Apr 28 14:26:46 2005] [info] Child process pid=30586 is exiting -
server pushEND in modperl_extra.pl, pid=30586
[Thu Apr 28 14:26:46 2005] [info] removed PID file
/opt/modperl/mod_perl-2.0.0-RC5/t/logs/httpd.pid (pid=30581)
[Thu Apr 28 14:26:46 2005] [notice] caught SIGTERM, shutting down
END in modperl_extra.pl, pid=30581
On Thu, 2005-04-28 at 11:36, Stas Bekman wrote:
> [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.
> >
> > The test failed as below (from t/logs/error_log).
> >
> > # Failed test 2 in
> > /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> > line 66
> > # Failed test 3 in
> > /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> > line 79
> > # Failed test 4 in
> > /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> > line 93
> > # Failed test 5 in
> > /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> > line 107
> >
> > Perl tested fine except for 6 tests that had an undefined symbol like
> > this:
> > ../lib/Memoize/t/tie......................../opt/perl/perl-5.8.6/perl:
> > relocation error: ../lib/auto/DB_File/DB_File.so: undefined symbol:
> > db_version
> >
> > DB_File.so and db_version were the same for all failures.
> >
> > The new bug report is attached below.
>
> Tom, please follow the instructions at:
> http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
> Thank you.
>
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
[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.
>
> The test failed as below (from t/logs/error_log).
>
> # Failed test 2 in
> /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> line 66
> # Failed test 3 in
> /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> line 79
> # Failed test 4 in
> /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> line 93
> # Failed test 5 in
> /opt/modperl/mod_perl-2.0.0-RC5/t/response/TestApache/subprocess.pm at
> line 107
>
> Perl tested fine except for 6 tests that had an undefined symbol like
> this:
> ../lib/Memoize/t/tie......................../opt/perl/perl-5.8.6/perl:
> relocation error: ../lib/auto/DB_File/DB_File.so: undefined symbol:
> db_version
>
> DB_File.so and db_version were the same for all failures.
>
> The new bug report is attached below.
Tom, please follow the instructions at:
http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
Thank you.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] modperl2 compile error
Posted by Stas Bekman <st...@stason.org>.
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 modperl_cmd.lo modperl_options.lo
[...]
>> modperl_exports.lo -Wl,-E
>> /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a
>> -L/opt/perl/lib/5.8.6/x86_64-linux/CORE -lperl -lnsl -ldl -lm -lcrypt
>> -lutil -lc \ -o mod_perl.so /usr/bin/ld:
>> /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a(DynaLoader.o):
>> relocation R_X86_64_32 can not be used when making a shared object;
>> recompile with -fPIC
^^^^^^^^^^^^^^^^^^^^
>> /opt/perl/lib/5.8.6/x86_64-linux/auto/DynaLoader/DynaLoader.a: could
>> not read symbols: Bad value
Tom, the answer is right there: you need to rebuild perl with -fPIC
>> *** /opt/perl/bin/perl -V
>> Dynamic Linking:
>> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
>> cccdlflags='-fpic', lddlflags='-shared'
^^^^^^^^^^^^^^^^^^^
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com