Re: Problems with apreq2 on OS X

Dave,

Ok, I feel dumm.

I would have never guessed this. I thought libapreq was part of 
mod_perl, and that when you compiled it it just was used by mod_perl. I 
kept seeing that library, but not making the connection!

Not a dumb question at all, but a good question. I'm just so out of date 
that I haven't fully realised mod_perl and libapreq2 are separate. In 
the Old'n days, it worked if you just installed mod_perl.

The reason I didn't have to do this on  my fedora box is because with 
fedora core, yum install does a pretty good job installing libapreq, and 
the module is included in the packaged httpd.conf.

use D'oh;

Thanks, and sorry for my grumblings! If I had read the INSTALL I 
probably would've seen that too.

Patrick



 Dave Viner wrote:

> this might be a dumb question, but have you checked that the apreq  
> module is loaded?
>
> LoadModule apreq_module    modules/mod_apreq2.so
>
> ?
>
> dave
>
> On Oct 29, 2006, at 12:23 PM, Patrick Galbraith wrote:
>
>> Fred Moyer wrote:
>>
>>> Patrick Galbraith wrote:
>>>
>>>> Fred,
>>>>
>>>> Ok: I have this failure on
>>>> 1. OS X
>>>> 2. Suse 10.0 amd 64
>>>> 3. Suse 9.3   intel 32
>>>>
>>>> Has anyone addressed this? This is what I would call severely  
>>>> broke. I would prefer not to use CGI. After this week, I think  
>>>> maybe the universe is telling me to learn PHP after all these  
>>>> years of being a perl developer.
>>>
>>>
>>>
>>> The short answer would be to use an earlier release of libapreq -  
>>> this only happened to me with the latest release.  Or use CGI for  
>>> now until it's fixed.  There's nothing wrong with using CGI while  
>>> this bug gets worked out, the api is the same for the most part.   
>>> libapreq is still in a development version, and chances are that  
>>> your application will not bottleneck on CGI.
>>>
>>> If you go to PHP, you should not expect a trouble free life :) I  
>>> don't have anything against PHP, but it has it's own set of  
>>> problems.  With development in any language, you need to make sure  
>>> that you keep a tight hold on your versions.  Using the latest  
>>> version of something isn't always the best move, as experience has  
>>> taught me.  It's nice to try it out and report bugs back, and  
>>> helpful to the development of the project, but use the version  that 
>>> works for you.
>>>
>>> I've dug around a bit in the code trying to resolve this issue,  but 
>>> it's a bit above my head right now.
>>
>>
>> Fred,
>>
>> I know, I'm just frustrated and venting after losing many hours of  
>> dev time. The reason CGI won't work in my case is I've written all  
>> this code as a handler and putting into CGI seems like it'd be a  lot 
>> of work.  Maybe not, I'm not sure what I would have to change  since 
>> I rely so much on the request object.
>>
>> When you say to use an earlier version of libapreq, do you mean  
>> version 1.0? That won't work because all the linux dists I deal  with 
>> are ones with pre-packaged mod_perl2 and apache2 (but haven't  been 
>> able to get apreq to compile correctly against those pre- package 
>> versions, trying everything from source).
>>
>> Thanks for your replies!
>>
>> Patrick
>>
>>
>>>
>>>>
>>>> Patrick
>>>>
>>>> Fred Moyer wrote:
>>>>
>>>>> Patrick Galbraith wrote:
>>>>>
>>>>>> [Sun Oct 29 12:38:27 2006] [notice] Apache/2.2.3 (Unix) mod_ssl/ 
>>>>>> 2.2.3 OpenSSL/0.9.8d DAV/2 mod_perl/2.0.2 Perl/v5.8.8  configured 
>>>>>> -- resuming normal operations
>>>>>> dyld: lazy symbol binding failed: Symbol not found:  
>>>>>> _apreq_handle_apache2
>>>>>>  Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/ 
>>>>>> darwin-2level/auto/APR/Request/Apache2/Apache2.bundle
>>>>>>  Expected in: dynamic lookup
>>>>>>
>>>>>> dyld: Symbol not found: _apreq_handle_apache2
>>>>>>  Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/ 
>>>>>> darwin-2level/auto/APR/Request/Apache2/Apache2.bundle
>>>>>>  Expected in: dynamic lookup
>>>>>>
>>>>>> [Sun Oct 29 12:38:38 2006] [notice] child pid 11206 exit signal  
>>>>>> Trace/BPT trap (5)
>>>>>>
>>>>>> OS X version: Darwin radha.local 8.8.1 Darwin Kernel Version  
>>>>>> 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/ 
>>>>>> RELEASE_I386 i386 i386
>>>>>>
>>>>>> Not sure what this is. Anyone encountered this before?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I ran into this also, same platform.  I have been digging around  
>>>>> a bit to see if I can resolve it but no luck so far - my foo in  
>>>>> this area isn't quite where it needs to be.  This works fine for  
>>>>> me on Linux though.
>>>>>
>>>>>> Also, is there a way to have access to things like $rec->param  
>>>>>> without having to use Apache2::Request/libapreq2? I ask this in  
>>>>>> case there is no solution for getting this to work, as well as  
>>>>>> on linux distributions I cannot get libapreq2 working.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> You can use CGI.  Are you hitting this same issue on Linux?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>