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?