You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Darryl Miles <da...@netbauds.net> on 2006/05/04 14:55:01 UTC
MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0: cannot
open shared object file)
I am auditing upgrading my development systems for HTTP 2.2.0 usage and
thought I should bring your attention the failed test cases. The host
linux system does not have any apache 2.2.x installation and no system
libaprutil-1 library, it does have a libaprutil-0 system library. I do
not think it is necessary to have to configure /etc/ld.so.conf to add
the custom apache build location in order for ld.so to find the library.
I believe the problem can easily be corrected by instructing the test
harness where to find and load the libaprutil-1.so.0 library from, as
this library is installed within the standard apache2 file layout
location of my customer apache 2.2 build. So I think that the mod_perl2
should as part of its 'make test' check that APR can be loaded and
resolve the filesystem path and force the best candidate library to be
loaded during the relevant tests.
Since the APR version and build is fairly tightly coupled with the HTTPD
then I would expect my usage case to be the 'ideal' installation so even
if I had a system wide libaprutil-1 library it would not get picked up,
since I have the ideal instance under the apache2 file layout.
My HTTPD was configured with a prefix=/opt/apache2_prefork.
I configured MP2 with:
$ perl Makefile.PL MP_APXS=/opt/apache2_prefork/bin/apxs
MP_APR_CONFIG=/opt/apache2_prefork/bin/apr-1-config
The basic error is with loading libaprutil-1.so.0 which I have as a file
$ make test
...SNIP...
t/apr-ext/base64........................Can't load '/data/testing/mod_perl-2.0.2/blib/arch/auto/APR/APR.so' for module APR: libaprutil-1.so.0: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DynaLoader.pm line 230.
at /data/testing/mod_perl-2.0.2/blib/lib/APR/Base64.pm line 23
Compilation failed in require at /data/testing/mod_perl-2.0.2/blib/lib/APR/Base64.pm line 23.
BEGIN failed--compilation aborted at /data/testing/mod_perl-2.0.2/blib/lib/APR/Base64.pm line 23.
Compilation failed in require at /data/testing/mod_perl-2.0.2/t/lib/TestAPRlib/base64.pm line 11.
BEGIN failed--compilation aborted at /data/testing/mod_perl-2.0.2/t/lib/TestAPRlib/base64.pm line 11.
Compilation failed in require at t/apr-ext/base64.t line 7.
BEGIN failed--compilation aborted at t/apr-ext/base64.t line 7.
t/apr-ext/base64........................dubious
Test returned status 255 (wstat 65280, 0xff00)
# ls -l /opt/apache2_prefork/lib/
total 1728
-rw-r--r-- 1 root root 7656 May 4 02:25 apr.exp
-rw-r--r-- 1 root root 3907 May 4 02:25 aprutil.exp
-rw-r--r-- 1 root root 631184 May 4 02:25 libapr-1.a
-rwxr-xr-x 1 root root 844 May 4 02:25 libapr-1.la
lrwxrwxrwx 1 root root 17 May 4 02:25 libapr-1.so -> libapr-1.so.0.2.2
lrwxrwxrwx 1 root root 17 May 4 02:25 libapr-1.so.0 -> libapr-1.so.0.2.2
-rwxr-xr-x 1 root root 414904 May 4 02:25 libapr-1.so.0.2.2
-rw-r--r-- 1 root root 401746 May 4 02:25 libaprutil-1.a
-rwxr-xr-x 1 root root 972 May 4 02:25 libaprutil-1.la
lrwxrwxrwx 1 root root 21 May 4 02:25 libaprutil-1.so -> libaprutil-1.so.0.2.2
lrwxrwxrwx 1 root root 21 May 4 02:25 libaprutil-1.so.0 -> libaprutil-1.so.0.2.2
-rwxr-xr-x 1 root root 269329 May 4 02:25 libaprutil-1.so.0.2.2
drwxr-xr-x 2 root root 4096 May 4 02:25 pkgconfig
Failure summary, all of these AFAICS are the same problem.
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/apr-ext/base64.t 255 65280 ?? ?? % ??
t/apr-ext/brigade.t 255 65280 ?? ?? % ??
t/apr-ext/bucket.t 255 65280 ?? ?? % ??
t/apr-ext/date.t 255 65280 ?? ?? % ??
t/apr-ext/error.t 255 65280 ?? ?? % ??
t/apr-ext/finfo.t 255 65280 ?? ?? % ??
t/apr-ext/os.t 255 65280 ?? ?? % ??
t/apr-ext/pool.t 255 65280 ?? ?? % ??
t/apr-ext/status.t 255 65280 ?? ?? % ??
t/apr-ext/string.t 255 65280 ?? ?? % ??
t/apr-ext/table.t 255 65280 ?? ?? % ??
t/apr-ext/threadmutex.t 255 65280 ?? ?? % ??
t/apr-ext/uri.t 255 65280 ?? ?? % ??
t/apr-ext/util.t 255 65280 ?? ?? % ??
t/apr-ext/uuid.t 255 65280 ?? ?? % ??
t/apr/constants.t 255 65280 ?? ?? % ??
10 tests skipped.
Failed 16/231 test scripts, 93.07% okay. 0/2208 subtests failed, 100.00% okay.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Darryl Miles wrote:
> I dont understand this in the context of my original email. Which only
> talks of "make test" test failures, under Linux with mod_perl-2.0.2 and
> Apache-httpd 2.2.0. This seems Off Topic to me.
Blarg... you're right, I missed the 'test' part. BOO!
I'll have to go re-read at a later point.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by Darryl Miles <da...@netbauds.net>.
Philip M. Gollucci wrote:
> Darryl Miles wrote:
>> I think you completely miss the point of my comments, but thanks for
>> your reply.
> No not really, I've fallen into this issue a plethora of times myself.
Hmm...
>> I agree *-0 and *-1 are different versions required for different
>> version of apache-httpd. As I stated I have a Linux distribution copy
>> of Apache 2.0.x, which uses *-0 (and I dont expect my apache 2.2.x to
>> use it in any way).
> The problem is the way configure is built in the APR distros .. it first
> searches and uses your path regardless of any options you specify
> (--with-apr, --with-apr-util). I've brought this up on dev (at) apr
> (dot) apache (dot) org before. Also, if you search the archives of this
> list, I believe joes commented on this too. You (we) should take this
> up there -- as mod_perl is just using what is reported to it by the
> apr-1-config or apr-0-config. I read both lists, so if you do move the
> discussion, I'll follow it.
I dont understand this in the context of my original email. Which only
talks of "make test" test failures, under Linux with mod_perl-2.0.2 and
Apache-httpd 2.2.0. This seems Off Topic to me.
>> My concern is that, if I have installed a perfect copy of Apache 2.2.x
>> using the Apache file layout then I should not need to configure
>> anything special for it to work. Nor configure anything special for
>> mod_perl2 to find the /opt/apache2_prefork/lib/libaprutil-1.so which I
>> have. That should work out-the-box.
> You know I wish it would -- installing /usr/ports/subversion or anything
> in FreeBSD/OpenBSD ports that installs an apr/apr-util in your default
> path wreaks havoc in this fashion.
Hey thats *BSD :). Any system admin who decides to alter their
system-wise libraries not doing it through their package manager is
really on their own here. My understanding of *BSD ports is they are
all installed into /usr/local from the package installed. It sounds
like you have an internal *BSD grumble at your ports maintainer(s), but
this is unrelated to my problem.
My example cites /opt (which should be free on both platforms) for the
system admin to install what the hell he wants.
I've been using /opt for over 10 years now to really great effect. Its
really simple for me, I turn off the distribution provided HTTPD (or
dont install it at all) and I install my own to /opt and maintain my own
upgrade cycles.
Exactly what I want and from an installation point of view "the perfect
install".
> The WORST problem is that even if you setup the LD_LIBRARY_PATH variable
> correctly, ANY library in your path matching is still linked in. This
> will get you duplicate linking of libraries which I _gaurantee_ will
> caus segfaults later (especially if they mix threads and no threads).
>
LD_LIBRARY_PATH must work differently on Linux then. If works just like
the $PATH in a shell. It finds the first and loads that and is happy.
I'm not sure there is a huge problem with Linux and thread and
non-thread libraries in the most part it just works and its doing the
correct thing.
> AFAIK, the only solution to this to to move them out of the way while
> building.
Again the problem here is "make test" so its only the mod-perl created
instance of apache-httpd I am referring to.
As system administrator I shall consult apache-httpd documentation over
the correct loading of libraries for the operational httpd server.
Which in effect means my wrapper script for httpd 2.2.x is updated to
setup LD_LIBRARY_PATH.
>> At this moment it does not work, I think thats very wrong. At the
>> least something like the ld.so environment variable equivalent
>> LD_PRELOAD=/opt/apache2_prefork/lib/libaprutil-1.so should be set
>> forcing a sane precedence order to load the DSOs.
> Sadly its not quite that simple as this path has to be permenately added
> to your search path or start/restart will fail after a reboot or in a
> different shell.
Again I think you are missing my point (and putting words in my mouth
when doing so). I am not talking about the operational start/restart
function of apache-httpd.
My original email only talks about "make test" from "mod_perl-2.0.2" not
working out of the box, for a Apache file layout installed copy of
Apache 2.2.0.
Obviously you have other historical issues of your own and are somehow
bundling them as the same as mine. Please dont do this.
> This might be a good idea with a little more work, but before I go
> changing anything if anyone else with a commit bit wants to chime in
> that would be good.
>
>> Maybe the ./configure script needs to add:
>>
>> export LD_LIBRARY_PATH="$apache_prefix/lib:"
> See above about about apr's configure
This works for me on Linux. I can't talk of *BSD. I suspect my script
fragment would work too on my platform if integrated into the
test-harness code that starts up apache-httpd server for the purpose of
running "make test".
[warning] server localhost.localdomain:8529 shutdown
All tests successful.
Files=17, Tests=82, 32 wallclock secs (21.25 cusr + 5.64 csys = 26.89 CPU)
I dont mean to be harsh, but you seem to have other problems on your
platform.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Darryl Miles wrote:
> I think you completely miss the point of my comments, but thanks for
> your reply.
No not really, I've fallen into this issue a plethora of times myself.
> I agree *-0 and *-1 are different versions required for different
> version of apache-httpd. As I stated I have a Linux distribution copy
> of Apache 2.0.x, which uses *-0 (and I dont expect my apache 2.2.x to
> use it in any way).
The problem is the way configure is built in the APR distros .. it first
searches and uses your path regardless of any options you specify
(--with-apr, --with-apr-util). I've brought this up on dev (at) apr
(dot) apache (dot) org before. Also, if you search the archives of this
list, I believe joes commented on this too. You (we) should take this
up there -- as mod_perl is just using what is reported to it by the
apr-1-config or apr-0-config. I read both lists, so if you do move the
discussion, I'll follow it.
> My concern is that, if I have installed a perfect copy of Apache 2.2.x
> using the Apache file layout then I should not need to configure
> anything special for it to work. Nor configure anything special for
> mod_perl2 to find the /opt/apache2_prefork/lib/libaprutil-1.so which I
> have. That should work out-the-box.
You know I wish it would -- installing /usr/ports/subversion or anything
in FreeBSD/OpenBSD ports that installs an apr/apr-util in your default
path wreaks havoc in this fashion.
The WORST problem is that even if you setup the LD_LIBRARY_PATH variable
correctly, ANY library in your path matching is still linked in. This
will get you duplicate linking of libraries which I _gaurantee_ will
caus segfaults later (especially if they mix threads and no threads).
AFAIK, the only solution to this to to move them out of the way while
building.
> At this moment it does not work, I think thats very wrong. At the least
> something like the ld.so environment variable equivalent
> LD_PRELOAD=/opt/apache2_prefork/lib/libaprutil-1.so should be set
> forcing a sane precedence order to load the DSOs.
Sadly its not quite that simple as this path has to be permenately added
to your search path or start/restart will fail after a reboot or in a
different shell.
This might be a good idea with a little more work, but before I go
changing anything if anyone else with a commit bit wants to chime in
that would be good.
> Maybe the ./configure script needs to add:
>
> export LD_LIBRARY_PATH="$apache_prefix/lib:"
See above about about apr's configure
P.S.
I feel your pain.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by Darryl Miles <da...@netbauds.net>.
Philip M. Gollucci wrote:
> This isn't actually mod_perl's fault.
> *-0 vs *-1 libraries and binaries are from DIFFERNT major versions of
> APR/APRUTIL.
>
> If they happen to be in your path (you said they are), then they get
> found and use even if you wan't them to (and sometimes if you specify
> not too). The easiest solution is to move them out side of any lib/bin
> PATHs and then compile
> httpd and let it install its own apr/apr-util.
>
> After that, the mod_perl compile with will use the apr-1-config and such
> will return the correct paths.
>
> Using ld.so.conf will likely not work. It might fix this error, but it
> was cause others.
I think you completely miss the point of my comments, but thanks for
your reply.
I agree *-0 and *-1 are different versions required for different
version of apache-httpd. As I stated I have a Linux distribution copy
of Apache 2.0.x, which uses *-0 (and I dont expect my apache 2.2.x to
use it in any way).
As stated the only copy of Apache 2.2.x is one I compiled and install to
/opt/apache2_prefork.
My concern is that, if I have installed a perfect copy of Apache 2.2.x
using the Apache file layout then I should not need to configure
anything special for it to work. Nor configure anything special for
mod_perl2 to find the /opt/apache2_prefork/lib/libaprutil-1.so which I
have. That should work out-the-box.
At this moment it does not work, I think thats very wrong. At the least
something like the ld.so environment variable equivalent
LD_PRELOAD=/opt/apache2_prefork/lib/libaprutil-1.so should be set
forcing a sane precedence order to load the DSOs.
Then part of my post went on to explain that even if I had a Linux
distribution copy of *-1 say at /usr/lib/libaprutil-1.so, if I am using
the Apache file layout and have /opt/apache2_prefork/lib/libaprutil-1.so
then my compiled version should always override the system /usr/lib copy.
Maybe the ./configure script needs to add:
export LD_LIBRARY_PATH="$apache_prefix/lib:"
In the correct place, "man 8 ld.so" can help here.
This sure is mod_perl's fault for not setting up the environment which
the HTTP server is running under in a sane manner in relation to what is
can learn from apxs/apr-1-config.
# This is worked out inside ./configure already
apr_config_path="/opt/apache2_prefork/bin/apr-1-config"
# If platform supports shlib-path-var configure it
ldso_varname=$(${apr_config_path} --shlib-path-var)
if [ "x${ldso_varname}" != "x" ]
then
apache_prefix=$(${apr_config_path} --prefix)
# Try to not override with a system default path,
# but /usr/local would be ok
if [ "${apache_prefix}" != "/" ] && \
[ "${apache_prefix}" != "/usr" ]
then
apache_libdir="${apache_prefix}/lib"
# Check dir exists
if [ -d "${apache_libdir}" ]
then
# Prepend directory to front of list
# export LD_LIBRARY_PATH="$apache_prefix/lib:"
tmp="${ldso_varname}"
set "${ldso_varname}=${apache_libdir}:${tmp}"
unset tmp
export "${ldso_varname}"
fi
fi
fi
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Darryl Miles wrote:
>
> I am auditing upgrading my development systems for HTTP 2.2.0 usage and
> thought I should bring your attention the failed test cases. The host
> linux system does not have any apache 2.2.x installation and no system
> libaprutil-1 library, it does have a libaprutil-0 system library. I do
> not think it is necessary to have to configure /etc/ld.so.conf to add
> the custom apache build location in order for ld.so to find the library.
> My HTTPD was configured with a prefix=/opt/apache2_prefork.
>
>
> I configured MP2 with:
>
> $ perl Makefile.PL MP_APXS=/opt/apache2_prefork/bin/apxs
> MP_APR_CONFIG=/opt/apache2_prefork/bin/apr-1-config
>
>
> The basic error is with loading libaprutil-1.so.0 which I have as a file
This isn't actually mod_perl's fault.
*-0 vs *-1 libraries and binaries are from DIFFERNT major versions of APR/APRUTIL.
If they happen to be in your path (you said they are), then they get found and
use even if you wan't them to (and sometimes if you specify not too). The
easiest solution is to move them out side of any lib/bin PATHs and then compile
httpd and let it install its own apr/apr-util.
After that, the mod_perl compile with will use the apr-1-config and such will
return the correct paths.
Using ld.so.conf will likely not work. It might fix this error, but it was
cause others.
HTH
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0:
cannot open shared object file)
Posted by Darryl Miles <da...@netbauds.net>.
Joe Orton wrote:
> On Thu, May 04, 2006 at 01:55:01PM +0100, Darryl Miles wrote:
> It's relatively simple to fix at least such that the tests work; the
> generated Makefile could set an LD_LIBRARY_PATH in the environment
> passed to t/TEST (PASSENV). But this wouldn't help the installed case;
> if you tried to use the Perl XS modules outside of httpd, then they
> could still fail to find the dependent libraries.
This is the only case I am requesting a fix for, the "make test" case.
The installed case it upto the system administrator and modperl2 release
notes to deal with from their /opt/apache/bin/apachectl script. As it
becomes a more general apache-httpd installation issue. The RPATH
suggestion was one way I know of to solve that but isn't the primary
reason for my mail.
"make test" should work out-the-box (if it can be made to) on as many
platforms as possible, this benefits the MP2 community with working
regression testing from the user end.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP2.0.2 + HTTPD 2.2.0 Linux test failures (libaprutil-1.so.0: cannot open shared object file)
Posted by Joe Orton <jo...@redhat.com>.
On Thu, May 04, 2006 at 01:55:01PM +0100, Darryl Miles wrote:
> I am auditing upgrading my development systems for HTTP 2.2.0 usage and
> thought I should bring your attention the failed test cases. The host
> linux system does not have any apache 2.2.x installation and no system
> libaprutil-1 library, it does have a libaprutil-0 system library. I do
> not think it is necessary to have to configure /etc/ld.so.conf to add
> the custom apache build location in order for ld.so to find the library.
>
> I believe the problem can easily be corrected by instructing the test
> harness where to find and load the libaprutil-1.so.0 library from, as
> this library is installed within the standard apache2 file layout
> location of my customer apache 2.2 build. So I think that the mod_perl2
> should as part of its 'make test' check that APR can be loaded and
> resolve the filesystem path and force the best candidate library to be
> loaded during the relevant tests.
The problem is a little tricky to solve.
libtool will ensure that the httpd binary has the right RPATHs set so
that it can always find the libapr and libaprutil libraries in the
library path, since it links against libapr-1.la and libaprutil-1.la.
So this works fine even if apr/apr-util are installed in non-system
library path. But this doesn't apply for the mod_perl XS modules since
they are not linked using libtool.
It's relatively simple to fix at least such that the tests work; the
generated Makefile could set an LD_LIBRARY_PATH in the environment
passed to t/TEST (PASSENV). But this wouldn't help the installed case;
if you tried to use the Perl XS modules outside of httpd, then they
could still fail to find the dependent libraries.
There are a few workarounds:
1) set (and export) LD_RUN_PATH to the path containing libapr/libaprutil
when building mod_perl. This will ensure that the built XS modules have
RPATHs pointing to the library paths.
2) adjust your system-wide /etc/ld.so.conf to pick up that same path as
you mention
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org