On Wed, 21 Apr 2004, Joe Schaefer wrote:
Randy Kobes <[EMAIL PROTECTED]> writes:
As a first step, I looked through the APR::* modules, and came up with the following (entry-level) dependencies on mod_perl.so:
Pool: modperl_interp_unselect (modperl_interp.c)
This one looks to be a PITA because of the (eventual) request_rec dependence.
Bucket: modperl_bucket_sv_create (modperl_bucket.c)
Simple fix- add
#include "modperl_bucket.c"
to APR__Bucket.h.
[...]
Table: modperl_hash_tie, modperl_hash_tied_object (modperl_util.c)
Simple fix: copy those two functions from modperl_util.c right into APR__Table.h.
The above fixes produce the following from `make`:
% for i in Bucket Brigade Pool Table; do echo "APR/$i/$i.so:"; > nm --dynamic blib/arch/Apache2/auto/APR/$i/$i.so | grep modperl; > done APR/Bucket/Bucket.so: 0000000000001b90 T modperl_bucket_sv_create APR/Brigade/Brigade.so: APR/Pool/Pool.so: U modperl_interp_unselect APR/Table/Table.so: 0000000000004cd0 T modperl_hash_tie 0000000000002590 T modperl_hash_tied_object
so IMO if we can figure out what to do about APR::Pool, the other changes needed (for apreq2's Apache::Request) will be straightforward.
For this, could we, like Stas suggested, just including at link time all the object files that make up mod_perl.so, instead of against mod_perl.so?
As Joe suggested my idea won't work, since by including all other object files we will introduce new dependencies on ap_, so we need to figure out how to handle the Pool.so to get rid of the dependency on request_rec.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
