>>>>> "Kyle" == Kyle Moffett <[EMAIL PROTECTED]> writes:

Kyle> Also, I am confused as to exactly what Apache::Request is, and where
Kyle> it is found, because all these work (and I've never installed a
Kyle> specific Apache::Request):

Kyle> [localhost:~] kyle% perl -MApache::Request -e '1'
Kyle> [localhost:~] kyle% perl -e 'use Apache::Request ()'
Kyle> [localhost:~] kyle% perldoc Apache::Request

The problem is that both Apache::Request and Apache::Cookie link in
libapreq (statically).  You can "use" one *or* the other in a given
mod_perl-enabled process, but if you try to "use" both, they both
publish the same libapreq's symbols, and you get a symbol clash.

One hacky solution is to have libapreq linked statically in with the
binary, then let the dynamic Apache/Request.so satisfy the libapreq
from there.  That's the approach taken by this proffered solution.  To
me... it seems an odd hack to have to make the core binary provide
callbacks needed by second-tier shared libs. :(

Of course, the only way I could get mod_perl to pull in .so's is to
link it statically, which also seems odd.  How could Apple have
screwed up the linker and dynloader so much?

Kyle> I don't know about custom-built dynamic ones, I just rebuilt my
Kyle> mod_perl static and this worked well.

Until you use both Apache::Request and Apache::Cookie, then Booom!

Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Fink-devel mailing list

Reply via email to