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

Re: [mp2] modperl2 compile error

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.