>>>>> "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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
