Re: Problems with apreq2 on OS X

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?
>>
>>
>>
>