I'm not exactly sure whats going on here (as I've been gone a while), but we
should consider this in the new branch addressing build changes and code splits.
http://svn.apache.org/viewcvs.cgi/httpd/apreq/branches/apr-build-system/
Cory Omand wrote:
Copying the list
---------- Forwarded message ----------
From: Cory Omand <[EMAIL PROTECTED]>
Date: Mar 30, 2006 11:57 AM
Subject: Re: Apache 2.2 and libapreq2 2.0.7 segfault
To: "Philip M. Gollucci" <[EMAIL PROTECTED]>
On 3/29/06, Philip M. Gollucci <[EMAIL PROTECTED]> wrote:
Can't load
'/export/medusa/comand/csw/cpan/libapreq2/work/comand-ra.d/libapreq2-2.07/glue/perl/t/cgi-bin/../../blib/arch/auto/APR/Request/Request.so'
for module APR::Request: ld.so.1: test_cgi.pl: fatal: libapreq2.so.3:
set the LD_LIBRARY_PATH in your shell to the appropriate paths. Thats
strange. This isn't your problem, but I'm hoping the test out will give me
something to go on. I'm having some "issues" looking at ndm instead of gdb.
It turned out that thanks to libtool, the module and library tests
were pointing to the uninstalled version of libapreq, allowing the
tests to run normally. However, the uninstalled glue Request.so
module was *not* pointing anywhere useful, and could not find either
libapreq2 or libapr/aprutil. No matter what I did, I could not make
the glue test suite utilize my LD_LIBRARY_PATH. Not sure why.
Copying the libs from library/.libs to the destination path before
running the tests finally allowed the tests to load the library.
Fixing the library loading issues unmasked a different set of test
failures. It appears that the test suite relies on 'perltoc.pod' and
'perlport.pod' being installed. My perl installation splits the pod
docs out from the core perl, and other distributions may do the same.
Perhaps relying on a pod that is required in the perl core (like
perldiag.pod, or Config.pm) might be a better idea?
After I installed the pod docs, all tests pass, but usage from within
Apache still yields a segfault when creating new Request objects. Now
I am extremely confused. I verified that the identical library
versions are present on the target system, and that all shared objects
are able to locate libapr/aprutil/apreq2. Any ideas?
- C.
--
------------------------------------------------------------------------
Philip M. Gollucci ([EMAIL PROTECTED]) 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..."
