You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/04/18 04:22:05 UTC
[mp2] decoupling APR from mod_perl
[xposting the modperl dev list]
Joe Schaefer wrote:
> Maybe a couple of us could get together on IRC sometime this month and
> sort out what needs to be done to make it happen. I'd be willing to
> dedicate some time to the effort it if I better understood what the
> relevant issues are for mp2, and what course of action you guys are
> taking/considering.
I believe the whole issue is relatively trivial: We need to take all the
functions that both mod_perl and APR libs rely on (that's the missing symbols
you've got reported when you tried to load APR::Table w/o mod_perl.so being
loaded and others used by other APR::* modules) and put them into a separate
.[ch] files, so both APR.so and mod_perl.so can include. We already do that
for modperl_constants.c, you can find a copy of
src/modules/perl/modperl_constants.c as xs/ModPerl/Const/modperl_constants.c.
So we just need to copy these new *[ch] files into xs/APR/APR and arrange for
build and inclusion of it in APR.so. And unless I've missed something it
should just work. APR.pm and ModPerl/Const.pm already make sure that they
won't attempt to load APR.so and Const.so if mod_perl.so is already loaded.
Notice that modperl-2.0/t/apr-ext files exercise the APR-w/o-mod_perl already
(at the moment it is only possible for some APR:: libs).
So if there is an urgency to resolve this issue now, we can do that.
Please notice that there are known problems with linking APR.so on some
platforms, I believe only Solaris was reported so far. Since I don't use
Solaris and nobody has volunteered help so far it's unresolved and t/apr-ext
tests fail on that platform.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>I believe the whole issue is relatively trivial: We need
[...]
> 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)
>
> Bucket: modperl_bucket_sv_create (modperl_bucket.c)
>
> OS: modperl_perl_sv_setref_uv (modperl_util.c)
> Socket,PerlIO: modperl_apr_strerror (modperl_util.c)
> Table: modperl_hash_tie, modperl_hash_tied_object
> (modperl_util.c)
> URI: modperl_uri_new (modperl_util.c)
>
> However, this isn't the whole story, as some of these
> functions call other functions that are also in mod_perl.so.
> For example, modperl_bucket_sv_create needs
> modperl_bucket_sv_make, which in turn needs MP_TRACE_f, and
> so on ... Similarily, modperl_interp_unselect needs
> modperl_config_request_cleanup (in modperl_config.c) and
> modperl_tipool_putback_data (in modperl_tipool.c), and so on
> ... Only the functions in modperl_util.c seem to not depend
> strongly on other modperl_* functions (just on stuff in the
> Perl and Apache libraries).
>
> I started to put together a single file with all the needed
> symbols, but it's getting pretty large, and then starts to
> fracture the existing structure. How about, for those files
> that are needed, splitting them up into two files (eg,
> modperl_util.c and modperl_util_apr.c), with the *_apr.c
> file containing the functions needed by APR::*. Sometimes it
> may not be possible to split them up (eg, I think everything
> in modperl_bucket.c is needed by APR::*).
Not pretty. I haven't thought of these further dependencies :( Thanks for
working on that, Randy!
> It also occurred to me though in trying to trace all the
> needed functions down - would it be easier to just treat
> mod_perl.so, when using the APR::* modules, as a needed .so
> that has to be loaded, like an Apache libapr*.so or like
> libapreq2.so? Or is there a performance hit with having more
> functions than needed in an so?
I think it's not the best idea to depend on mod_perl.so, since it may be not
included in some distros which may want to distribute just the binary perl
glue for APR (e.g. from APR site). Plus mod_perl.so usually doesn't live under
the perl tree, so it'll just require a way too much mess with configuration
and unnecessary headaches to people who need to support the sw using APR::
(not talking about the users).
I suggest that as a first quick fix we simply link APR.so with all the same .o
files mod_perl.so is linked with, which immediatelly resolves the problem w/o
requiring to mess up with the files. Later on we can think how to handle it
more gracefully if at all.
Performance wise: APR.so will be a bigger file to read into the memory, but I
don't think the loader reads the file, usually it mmaps it. Then the symbol
resolution stage comes. On most platforms symbols resolution happens on
demand, so it shouldn't be an issue. Indeed on those platforms that do
RTLD_NOW all these irrelevant symbols will add to the loading time. But given
that mod_cgi is pretty slow already, it probably won't make much difference.
Though I haven't benchmarked that, so I could be totally wrong.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>I believe the whole issue is relatively trivial: We need
[...]
> 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)
>
> Bucket: modperl_bucket_sv_create (modperl_bucket.c)
>
> OS: modperl_perl_sv_setref_uv (modperl_util.c)
> Socket,PerlIO: modperl_apr_strerror (modperl_util.c)
> Table: modperl_hash_tie, modperl_hash_tied_object
> (modperl_util.c)
> URI: modperl_uri_new (modperl_util.c)
>
> However, this isn't the whole story, as some of these
> functions call other functions that are also in mod_perl.so.
> For example, modperl_bucket_sv_create needs
> modperl_bucket_sv_make, which in turn needs MP_TRACE_f, and
> so on ... Similarily, modperl_interp_unselect needs
> modperl_config_request_cleanup (in modperl_config.c) and
> modperl_tipool_putback_data (in modperl_tipool.c), and so on
> ... Only the functions in modperl_util.c seem to not depend
> strongly on other modperl_* functions (just on stuff in the
> Perl and Apache libraries).
>
> I started to put together a single file with all the needed
> symbols, but it's getting pretty large, and then starts to
> fracture the existing structure. How about, for those files
> that are needed, splitting them up into two files (eg,
> modperl_util.c and modperl_util_apr.c), with the *_apr.c
> file containing the functions needed by APR::*. Sometimes it
> may not be possible to split them up (eg, I think everything
> in modperl_bucket.c is needed by APR::*).
Not pretty. I haven't thought of these further dependencies :( Thanks for
working on that, Randy!
> It also occurred to me though in trying to trace all the
> needed functions down - would it be easier to just treat
> mod_perl.so, when using the APR::* modules, as a needed .so
> that has to be loaded, like an Apache libapr*.so or like
> libapreq2.so? Or is there a performance hit with having more
> functions than needed in an so?
I think it's not the best idea to depend on mod_perl.so, since it may be not
included in some distros which may want to distribute just the binary perl
glue for APR (e.g. from APR site). Plus mod_perl.so usually doesn't live under
the perl tree, so it'll just require a way too much mess with configuration
and unnecessary headaches to people who need to support the sw using APR::
(not talking about the users).
I suggest that as a first quick fix we simply link APR.so with all the same .o
files mod_perl.so is linked with, which immediatelly resolves the problem w/o
requiring to mess up with the files. Later on we can think how to handle it
more gracefully if at all.
Performance wise: APR.so will be a bigger file to read into the memory, but I
don't think the loader reads the file, usually it mmaps it. Then the symbol
resolution stage comes. On most platforms symbols resolution happens on
demand, so it shouldn't be an issue. Indeed on those platforms that do
RTLD_NOW all these irrelevant symbols will add to the loading time. But given
that mod_cgi is pretty slow already, it probably won't make much difference.
Though I haven't benchmarked that, so I could be totally wrong.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> > [...]
> >
> >>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.
> > Right- it looks pretty tricky to me because of how mp2's ithread pools
> > interacts with the APR::Pool's cleanup callbacks. Because of this, I'm
> > tempted to suggest that the current APR::Pool implementation should be
> > renamed Apache::Pool, and a new (simpler) base class APR::Pool should be
> > constructed that doesn't rely on ap_*.
>
> Yes, that's quite possible. I didn't have a chance to look at it though.
I think it just boils down to removing this portion of mpxs_cleanup_run()
from APR__Pool.h:
#ifdef USE_ITHREADS
if (cdata->interp) {
/* this will decrement the interp refcnt until
* there are no more references, in which case
* the interpreter will be putback into the mip
*/
(void)modperl_interp_unselect(cdata->interp);
}
#endif
and making a new class, Apache::Pool, that is derived from APR::Pool.
You then need to install a few XSUBs for Apache::Pool that will run this
section as necessary.
Just a quick guess, but I don't believe it's too far off.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>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.
>
>
> Right- it looks pretty tricky to me because of how mp2's
> ithread pools interacts with the APR::Pool's cleanup callbacks.
> Because of this, I'm tempted to suggest that the current APR::Pool
> implementation should be renamed Apache::Pool, and a new (simpler)
> base class APR::Pool should be constructed that doesn't rely on ap_*.
Yes, that's quite possible. I didn't have a chance to look at it though.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> 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.
Right- it looks pretty tricky to me because of how mp2's
ithread pools interacts with the APR::Pool's cleanup callbacks.
Because of this, I'm tempted to suggest that the current APR::Pool
implementation should be renamed Apache::Pool, and a new (simpler)
base class APR::Pool should be constructed that doesn't rely on ap_*.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 21 Apr 2004, Joe Schaefer wrote:
>
>
>>Randy Kobes <ra...@theoryx5.uwinnipeg.ca> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 21 Apr 2004, Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> 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?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> 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.
> It also occurred to me though in trying to trace all the
> needed functions down - would it be easier to just treat
> mod_perl.so, when using the APR::* modules, as a needed .so
> that has to be loaded, like an Apache libapr*.so or like
> libapreq2.so?
That doesn't really help because of mod_perl.so's ap_*
dependence. There's no libhttpd on *nix that will resolve
the missing ap_* symbols from mod_perl.so.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 17 Apr 2004, Stas Bekman wrote:
> [xposting the modperl dev list]
>
> Joe Schaefer wrote:
>
> > Maybe a couple of us could get together on IRC sometime
> > this month and sort out what needs to be done to make it
> > happen. I'd be willing to dedicate some time to the
> > effort it if I better understood what the relevant
> > issues are for mp2, and what course of action you guys
> > are taking/considering.
>
> I believe the whole issue is relatively trivial: We need
> to take all the functions that both mod_perl and APR libs
> rely on (that's the missing symbols you've got reported
> when you tried to load APR::Table w/o mod_perl.so being
> loaded and others used by other APR::* modules) and put
> them into a separate .[ch] files, so both APR.so and
> mod_perl.so can include. We already do that for
> modperl_constants.c, you can find a copy of
> src/modules/perl/modperl_constants.c as
> xs/ModPerl/Const/modperl_constants.c. So we just need to
> copy these new *[ch] files into xs/APR/APR and arrange for
> build and inclusion of it in APR.so. And unless I've
> missed something it should just work. APR.pm and
> ModPerl/Const.pm already make sure that they won't attempt
> to load APR.so and Const.so if mod_perl.so is already
> loaded.
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)
Bucket: modperl_bucket_sv_create (modperl_bucket.c)
OS: modperl_perl_sv_setref_uv (modperl_util.c)
Socket,PerlIO: modperl_apr_strerror (modperl_util.c)
Table: modperl_hash_tie, modperl_hash_tied_object
(modperl_util.c)
URI: modperl_uri_new (modperl_util.c)
However, this isn't the whole story, as some of these
functions call other functions that are also in mod_perl.so.
For example, modperl_bucket_sv_create needs
modperl_bucket_sv_make, which in turn needs MP_TRACE_f, and
so on ... Similarily, modperl_interp_unselect needs
modperl_config_request_cleanup (in modperl_config.c) and
modperl_tipool_putback_data (in modperl_tipool.c), and so on
... Only the functions in modperl_util.c seem to not depend
strongly on other modperl_* functions (just on stuff in the
Perl and Apache libraries).
I started to put together a single file with all the needed
symbols, but it's getting pretty large, and then starts to
fracture the existing structure. How about, for those files
that are needed, splitting them up into two files (eg,
modperl_util.c and modperl_util_apr.c), with the *_apr.c
file containing the functions needed by APR::*. Sometimes it
may not be possible to split them up (eg, I think everything
in modperl_bucket.c is needed by APR::*).
It also occurred to me though in trying to trace all the
needed functions down - would it be easier to just treat
mod_perl.so, when using the APR::* modules, as a needed .so
that has to be loaded, like an Apache libapr*.so or like
libapreq2.so? Or is there a performance hit with having more
functions than needed in an so?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] decoupling APR from mod_perl
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 17 Apr 2004, Stas Bekman wrote:
> [xposting the modperl dev list]
>
> Joe Schaefer wrote:
>
> > Maybe a couple of us could get together on IRC sometime
> > this month and sort out what needs to be done to make it
> > happen. I'd be willing to dedicate some time to the
> > effort it if I better understood what the relevant
> > issues are for mp2, and what course of action you guys
> > are taking/considering.
>
> I believe the whole issue is relatively trivial: We need
> to take all the functions that both mod_perl and APR libs
> rely on (that's the missing symbols you've got reported
> when you tried to load APR::Table w/o mod_perl.so being
> loaded and others used by other APR::* modules) and put
> them into a separate .[ch] files, so both APR.so and
> mod_perl.so can include. We already do that for
> modperl_constants.c, you can find a copy of
> src/modules/perl/modperl_constants.c as
> xs/ModPerl/Const/modperl_constants.c. So we just need to
> copy these new *[ch] files into xs/APR/APR and arrange for
> build and inclusion of it in APR.so. And unless I've
> missed something it should just work. APR.pm and
> ModPerl/Const.pm already make sure that they won't attempt
> to load APR.so and Const.so if mod_perl.so is already
> loaded.
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)
Bucket: modperl_bucket_sv_create (modperl_bucket.c)
OS: modperl_perl_sv_setref_uv (modperl_util.c)
Socket,PerlIO: modperl_apr_strerror (modperl_util.c)
Table: modperl_hash_tie, modperl_hash_tied_object
(modperl_util.c)
URI: modperl_uri_new (modperl_util.c)
However, this isn't the whole story, as some of these
functions call other functions that are also in mod_perl.so.
For example, modperl_bucket_sv_create needs
modperl_bucket_sv_make, which in turn needs MP_TRACE_f, and
so on ... Similarily, modperl_interp_unselect needs
modperl_config_request_cleanup (in modperl_config.c) and
modperl_tipool_putback_data (in modperl_tipool.c), and so on
... Only the functions in modperl_util.c seem to not depend
strongly on other modperl_* functions (just on stuff in the
Perl and Apache libraries).
I started to put together a single file with all the needed
symbols, but it's getting pretty large, and then starts to
fracture the existing structure. How about, for those files
that are needed, splitting them up into two files (eg,
modperl_util.c and modperl_util_apr.c), with the *_apr.c
file containing the functions needed by APR::*. Sometimes it
may not be possible to split them up (eg, I think everything
in modperl_bucket.c is needed by APR::*).
It also occurred to me though in trying to trace all the
needed functions down - would it be easier to just treat
mod_perl.so, when using the APR::* modules, as a needed .so
that has to be loaded, like an Apache libapr*.so or like
libapreq2.so? Or is there a performance hit with having more
functions than needed in an so?
--
best regards,
randy