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?
