Loading ...
Sorry, an error occurred while loading the content.

[mp2] modperl2 compile error

Expand Messages
  • Tom Caldwell
    Message 1 of 18 , Apr 27, 2005
    • 0 Attachment
      > -------------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<----------
      >
    • Stas Bekman
      ... [...] ... Tom, the answer is right there: you need to rebuild perl with -fPIC ... ^^^^^^^^^^^^^^^^^^^ --
      Message 2 of 18 , Apr 27, 2005
      • 0 Attachment
        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@... http://use.perl.org http://apacheweek.com
        http://modperlbook.org http://apache.org http://ticketmaster.com
      • Stas Bekman
        [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, please follow the
        Message 3 of 18 , Apr 28, 2005
        • 0 Attachment
          [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@... http://use.perl.org http://apacheweek.com
          http://modperlbook.org http://apache.org http://ticketmaster.com
        • Tom Caldwell
          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
          Message 4 of 18 , Apr 28, 2005
          • 0 Attachment
            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.
            >
          • Stas Bekman
            ... [...] ... 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
            Message 5 of 18 , Apr 28, 2005
            • 0 Attachment
              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@... http://use.perl.org http://apacheweek.com
              http://modperlbook.org http://apache.org http://ticketmaster.com
            • Tom Caldwell
              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
              Message 6 of 18 , Apr 29, 2005
              • 0 Attachment
                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
              • Stas Bekman
                ... Of course. In which case you need to check apache instead of nobody . ... No worries. ... su - apache ... is it possible that this path it not readable
                Message 7 of 18 , Apr 29, 2005
                • 0 Attachment
                  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@... http://use.perl.org http://apacheweek.com
                  http://modperlbook.org http://apache.org http://ticketmaster.com
                • Marc Gràcia
                  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
                  Message 8 of 18 , May 2, 2005
                  • 0 Attachment
                    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.
                    
                    
                  • Stas Bekman
                    ... That s correct, Marc. ... I supposed that Tom has recompiled everything after rebuilding perl. mod_perl will pick up -fPIC automatically at compile time,
                    Message 9 of 18 , May 2, 2005
                    • 0 Attachment
                      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@... http://use.perl.org http://apacheweek.com
                      http://modperlbook.org http://apache.org http://ticketmaster.com
                    • Tom Caldwell
                      Comments below. ... Well, the LD_LIBRARY_PATH gets set during the bash startup (.bashrc) so if the test does su - nobody - then the variable should be
                      Message 10 of 18 , May 2, 2005
                      • 0 Attachment
                        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.
                      • Stas Bekman
                        [CC ing the list back] ... Hmm, that s a good question. I think you need Apache2 too. ... I think not. As mod_perl.so gets loaded into httpd, they should be
                        Message 11 of 18 , May 2, 2005
                        • 0 Attachment
                          [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 libperl.so created by the modperl build.
                          >
                          > Is that correct?

                          I think not. As mod_perl.so gets loaded into httpd, they should be
                          compiled with the same flags.

                          I'm not 100% sure. Hopefully someone will correct me if I'm wrong. But
                          give it a try.

                          --
                          __________________________________________________________________
                          Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                          http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                          mailto:stas@... http://use.perl.org http://apacheweek.com
                          http://modperlbook.org http://apache.org http://ticketmaster.com
                        • Stas Bekman
                          ... so if you dump %ENV from your modperl handler, is it there? ... yes, sorry ... t/apache/subprocess.t is the client part.
                          Message 12 of 18 , May 2, 2005
                          • 0 Attachment
                            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@... http://use.perl.org http://apacheweek.com
                            http://modperlbook.org http://apache.org http://ticketmaster.com
                          • Marc Gràcia
                            El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va ... Yes that s Ok for all perl modules. But BTW, my Perl Compilation did not put automaticaly
                            Message 13 of 18 , May 4, 2005
                            • 0 Attachment
                              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 <mgracia@...>
                            • Tom Caldwell
                              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
                              Message 14 of 18 , May 4, 2005
                              • 0 Attachment
                                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
                                <mgracia@...> 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 <mgracia@...>




                                Tom Caldwell
                                Vanderbilt University Medical Center
                              • Marc Gràcia
                                El dc 04 de 05 del 2005 a les 10:09 -0500, en/na Tom Caldwell va ... Ok, If Perl is configured OK, mod_perl gets the args from Perl and everytning goes well,
                                Message 15 of 18 , May 5, 2005
                                • 0 Attachment
                                  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 
                                  <mgracia@...> 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 <mgracia@...>
                                  
                                  
                                  
                                  
                                  Tom Caldwell
                                  Vanderbilt University Medical Center
                                  
                                  
                                  
                                • Stas Bekman
                                  ... 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. --
                                  Message 16 of 18 , May 5, 2005
                                  • 0 Attachment
                                    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@... http://use.perl.org http://apacheweek.com
                                    http://modperlbook.org http://apache.org http://ticketmaster.com
                                  • Tom Caldwell
                                    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
                                    Message 17 of 18 , May 9, 2005
                                    • 0 Attachment
                                      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
                                      <stas@...> 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@... http://use.perl.org http://apacheweek.com
                                      > http://modperlbook.org http://apache.org http://ticketmaster.com




                                      Tom Caldwell
                                      Vanderbilt University Medical Center
                                    • Stas Bekman
                                      ... 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
                                      Message 18 of 18 , May 9, 2005
                                      • 0 Attachment
                                        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@... http://use.perl.org http://apacheweek.com
                                        http://modperlbook.org http://apache.org http://ticketmaster.com
                                      Your message has been successfully submitted and would be delivered to recipients shortly.