Re: libapreq 2.12 failing with apache 2.2.14
Howdy, Just built libapreq 2.12 on 64 bit CentOS 5.4 with Perl 5.10.1 and Apache 2.2.14, and found two things I wanted to follow up on here: 1. The build initially failed with this error: /usr/lib/libexpat.so: could not read symbols: File in wrong format This appears to be because I have 64 bit Apache and apreq, but that library is 32 bit. To get apreq to use the 64 bit version, I had to configure like so: LDFLAGS=-L/usr/lib64 ./configure --with-apache2-apxs=/path/to/apxs So is there some way that apreq2's configure script could be updated to look for /usr/lib64 and perhaps /lib64 and /usr/local/lib64 on 64 bit platforms? 2. I got a bunch of Perl test failures, but it looks like they were known. It doesn't look like this patch has been applied yet: http://marc.info/?l=apreq-dev&m=125501679623914 Should it be? Thanks, David
Re: libapreq 2.12 failing with apache 2.2.14
- Original Message > From: Clinton Gormley > To: apreq-dev > Sent: Wednesday, October 7, 2009 6:19:44 AM > Subject: Re: libapreq 2.12 failing with apache 2.2.14 > > > I'm installing apache 2.2.14 with libapreq 2.12, perl 5.8.9 and I'm > > getting the failures listed below. > > OK - turns out all of the failures are about the file type: > expected: text/x-pod > received: text/x-plain > > Although, I don't understand how the mime type could ever be text/x-pod. > > The test uses UPLOAD_BODY to upload the file, which in turn relies (via > HTTP::Request::Common) on LWP::MediaTypes, which has no definition for > text/x-pod. LWP recently changed the LWP/media.types file, pulling the cooked definition for the .pod extension. The reason it's now text/plain (not text/x-plain) is because LWP::MediaTypes guesses the content type using the "-T" function in perl. Can you write a patch for our tests that just checks for "text/*"? > > Is this just a bad test? Well they're dependent on LWP not being stupid with mime types and changing them without any notice. The fails aren't in any indicative of a problem with apreq's codebase.
Re: libapreq 2.12 failing with apache 2.2.14
> If you were referring to 5.10*, I can't use that version > because of certain bugs that haven't been fixed - they > keep throwing errors in my app. Duh yeah that's what I meant. I know with 5.8.8 there were a lot of problems because of a bug in ExtUtils::ParseXS, there was a recent fix that was supposed to fix this, does it help to upgrade that and/or other core ExtUtils modules? Mark