Re: [mp2] modperl2 compile error

[prev] [thread] [next] [Date index for 2005/05/09]

Stas and Marc,

So after a week hiatus I was finally able to return to my=20
Perl/ModPerl2/Apache2 woes on my Dell 64bit box running redhat=20
linux.

When we last left the main saga, I had just rebuilt perl and=20
modperl with the -fPIC flag only to find that the tests for=20
subprocess.t would not work. I tried several suggestions from Stas=20
but nothing worked. Mark suggested recompiling apache as well and=20
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=20
subprocess.t even after another modperl rebuild. So I did another=20
reinstall of perl. This time during the configure operation when=20
the script prompted for directories to search for standard libs the =

defaults were /usr/local/lib /lib /usr/lib (as before). After=20
checking out the original redhat installed version of perl (from=20
rpm vesion 5.8.0), I noticed that it used mostly libs from /lib64=20
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=20
default libs it had all the ones I needed as the default value=20
which it had failed to do before. I still had to change the link=20
flags from -fpic to -fPIC and replace the default link switches=20
with values I found in the redhat perl, but then all of the tests=20
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=20
<stas@xxxxxx.xxx> wrote:

> Marc Gr=E0cia wrote:
>> El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va
>> escriure:
>>
>>
>>> Marc Gr=E0cia 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@xxxxxx.xxx http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   =
http://ticketmaster.com




Tom Caldwell
Vanderbilt University Medical Center