You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2004/06/28 21:02:28 UTC
mod_perl.so dependencies in xs/typemap
As part of the effort to allow APR:: stuff
to work outside of mp2, the xs/typemap file
also needs examination: T_HASHOBJ, T_UVOBJ
both have modperl_ dependencies. T_HASHOBJ
is problematic for apreq, because there are
API's like $upload->info that are meant to
return APR::Table objects, but they currently
are broken in apreq2 because we use the
generic T_PTROBJ instead of the correct T_HASHOBJ
(because of the mod_perl.so dependency).
Not sure what the best fix for this is, so
I just thought I'd metion the issue and see what
folks think.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
[...]
> I'm not totally clear on how this works, and I can't test
> this on my linux machine right now as the mp2 stuff is on a
> live server. But, if you link against the mod_perl lib when
> compiling apreq2, but then use APR.so (which supplies
> modperl_hash_tie, modperl_hash_tied_object, and
> modperl_perl_sv_setref_uv, through
> src/modules/perl/modperl_common_util.c), will
> apreq2 be able to use those symbols from APR.so,
> and not demand mod_perl.so be available at run time?
Not sure what happens when you mix run-time and compile-time
linking- I suspect the behavior will be non-portable even
across ELF systems.
> On Win32 (and perhaps some others, like AIX), one could
> do this by making available the static aprext lib which
> supplies these symbols. For this one should have mp2 install
> it under, eg, $APACHE2/lib/ - it might be an idea to
> change the name to something like modperl_aprext.lib.
Even simpler would be to just move the definitions
into a separate header file, like say modperl_xs_inline.h.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 28 Jun 2004, Joe Schaefer wrote:
> As part of the effort to allow APR:: stuff
> to work outside of mp2, the xs/typemap file
> also needs examination: T_HASHOBJ, T_UVOBJ
> both have modperl_ dependencies. T_HASHOBJ
> is problematic for apreq, because there are
> API's like $upload->info that are meant to
> return APR::Table objects, but they currently
> are broken in apreq2 because we use the
> generic T_PTROBJ instead of the correct T_HASHOBJ
> (because of the mod_perl.so dependency).
>
> Not sure what the best fix for this is, so
> I just thought I'd metion the issue and see what
> folks think.
I'm not totally clear on how this works, and I can't test
this on my linux machine right now as the mp2 stuff is on a
live server. But, if you link against the mod_perl lib when
compiling apreq2, but then use APR.so (which supplies
modperl_hash_tie, modperl_hash_tied_object, and
modperl_perl_sv_setref_uv, through
src/modules/perl/modperl_common_util.c), will
apreq2 be able to use those symbols from APR.so,
and not demand mod_perl.so be available at run time?
On Win32 (and perhaps some others, like AIX), one could
do this by making available the static aprext lib which
supplies these symbols. For this one should have mp2 install
it under, eg, $APACHE2/lib/ - it might be an idea to
change the name to something like modperl_aprext.lib.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 29 Jun 2004, Stas Bekman wrote:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>>>
>>>
>>>>Joe Schaefer wrote:
>>>>
>>>>
>>>>>As part of the effort to allow APR:: stuff
>>>>>to work outside of mp2, the xs/typemap file
>>>>>also needs examination: T_HASHOBJ, T_UVOBJ
>>>>>both have modperl_ dependencies.
>>>>
>>>>I'm not quite following, what kind of deps you are talking about,
>>>>Joe. e.g. T_HASHOBJ uses modperl_hash_tie which now resides in APR.so
>>>>and doesn't require mod_perl. Can you give me an example of how this
>>>>problem can be seen?
>>>
>>>It'll only manifest in apreq2 on Win32, unless Randy figures out
>>>how to link Upload.dll against APR.dll.
>>
>>I guess this is the best solution.
>
>
> Actually, modperl_hash_tie (and the other functions from
> src/modules/perl/*.c that are provided by APR.so on *nix)
> are supplied by the static aprext library on Win32. So I
> think the most straightforward solution on Win32 is to
> arrange to have aprext.lib installed by mp2 into the Apache2
> lib/ directory, so that 3rd party modules have access to any
> of these functions. For this it might be a good idea to
> rename the library to, eg, modperl_aprext.lib, to indicate
> better where it came from. If that's acceptable, I'll make
> up a patch for that - it's just a few lines to change.
If that does the trick go for it. And +1 to rename.
>>I have a different take on this whole never-ending win32
>>mess -- since 99.99% of win32 users use precompiled
>>packages, may be it's a total waste of time and messing up
>>of the code to make things easy to build on win32? If
>>there is only one or few people who make binary distros,
>>may be they could write a few scripts that will build mp2
>>and libapreq by hardcoding paths, using .o files directly
>>and what not, keeping the core simple?
>>
>>But then again, there is AIX which seems to be very
>>similar to win32 when it comes to linking.
>
>
> I guess the similarity of AIX and Win32 in this respect is a
> consideration ... Of course, I'm not happy either with all
> the branching Win32 introduces (although it's a nice
> challenge to try to keep it to a minimum :). I wouldn't want
> to see support for Win32 disappear from the core, though, as
> - building things for Win32 would then become more dependent
> on a select few, who in the long term may change, and so
> the support base would shrink significantly;
> - it'd be much harder to track down problems on Win32 if
> one then has to factor in possible problems in
> Win32-specific build scripts;
> - it would make it that much harder to encourage
> Win32 developers to participate.
> - more often than not the Win32 branching is due to
> changes in the core code (eg, a .c/.h/.xs file),
> rather than a pure build problem, and it would be really
> difficult to maintain a complete Win32 mod_perl branch.
> - other projects build mod_perl for their distributions (eg,
> IndigoPerl at http://www.indigostar.com/ and
> DeveloperSide.net at http://www.devside.net/), and if
> mod_perl didn't compile easily from the sources, they'd
> probably drop it;
Ah, sorry, I didn't suggest to drop support for win32 build in the core. Just
suggesting to may be break the build process into blocks, which can then be
combined by some sort of script that will be run by win32 users. e.g. always
building libapreq+mp2 together, and re-using .o objects from the mp2 source
instead of figuring out where that extra library lives... but then there may
be other 3rd party modules that will have similar issues...
> Again, I'm not happy with the branching, and realize not too
> many people build mp/apreq on Win32 - the thing that mostly
> keeps me going, in addition to pure interest, is that there
> does seem to be a good-sized user base of the Win32 binary
> distributions - around 40 downloads per day on average of
> the Perl/Apache binary on the Apache site (and this is just
> one of several such all-in-one packages), and around the
> same number for the ppm packages.
Right. It's a stick of two edges. You mentioned one edge. The other edge is by
adding branching complexity you also make it harder for new people to join,
risking with too few people knowing their way around, ending up with a huge
spaghetti of code which becomes less and less maintainable. That's why some
time ago, I suggested an idea of subclasses where win32 will implement its own
nuances in its own subs, leaving the core alone. Granted that creates an
enormous initial overhead for you Randy to do that split, but on the other
hand it may attract more people to do the maintenance/development when there
will be significantly less branching. Though I release that I'm sliding off
the real topic, which is not the code branching but install issue on win32,
which while just as annoying, is a different issue :)
--
__________________________________________________________________
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: mod_perl.so dependencies in xs/typemap
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jun 2004, Stas Bekman wrote:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>Joe Schaefer wrote:
> >>
> >>>As part of the effort to allow APR:: stuff
> >>>to work outside of mp2, the xs/typemap file
> >>>also needs examination: T_HASHOBJ, T_UVOBJ
> >>>both have modperl_ dependencies.
> >>
> >>I'm not quite following, what kind of deps you are talking about,
> >>Joe. e.g. T_HASHOBJ uses modperl_hash_tie which now resides in APR.so
> >>and doesn't require mod_perl. Can you give me an example of how this
> >>problem can be seen?
> >
> > It'll only manifest in apreq2 on Win32, unless Randy figures out
> > how to link Upload.dll against APR.dll.
>
> I guess this is the best solution.
Actually, modperl_hash_tie (and the other functions from
src/modules/perl/*.c that are provided by APR.so on *nix)
are supplied by the static aprext library on Win32. So I
think the most straightforward solution on Win32 is to
arrange to have aprext.lib installed by mp2 into the Apache2
lib/ directory, so that 3rd party modules have access to any
of these functions. For this it might be a good idea to
rename the library to, eg, modperl_aprext.lib, to indicate
better where it came from. If that's acceptable, I'll make
up a patch for that - it's just a few lines to change.
[ ... ]
> I have a different take on this whole never-ending win32
> mess -- since 99.99% of win32 users use precompiled
> packages, may be it's a total waste of time and messing up
> of the code to make things easy to build on win32? If
> there is only one or few people who make binary distros,
> may be they could write a few scripts that will build mp2
> and libapreq by hardcoding paths, using .o files directly
> and what not, keeping the core simple?
>
> But then again, there is AIX which seems to be very
> similar to win32 when it comes to linking.
I guess the similarity of AIX and Win32 in this respect is a
consideration ... Of course, I'm not happy either with all
the branching Win32 introduces (although it's a nice
challenge to try to keep it to a minimum :). I wouldn't want
to see support for Win32 disappear from the core, though, as
- building things for Win32 would then become more dependent
on a select few, who in the long term may change, and so
the support base would shrink significantly;
- it'd be much harder to track down problems on Win32 if
one then has to factor in possible problems in
Win32-specific build scripts;
- it would make it that much harder to encourage
Win32 developers to participate.
- more often than not the Win32 branching is due to
changes in the core code (eg, a .c/.h/.xs file),
rather than a pure build problem, and it would be really
difficult to maintain a complete Win32 mod_perl branch.
- other projects build mod_perl for their distributions (eg,
IndigoPerl at http://www.indigostar.com/ and
DeveloperSide.net at http://www.devside.net/), and if
mod_perl didn't compile easily from the sources, they'd
probably drop it;
Again, I'm not happy with the branching, and realize not too
many people build mp/apreq on Win32 - the thing that mostly
keeps me going, in addition to pure interest, is that there
does seem to be a good-sized user base of the Win32 binary
distributions - around 40 downloads per day on average of
the Perl/Apache binary on the Apache site (and this is just
one of several such all-in-one packages), and around the
same number for the ppm packages.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> On Tue, 29 Jun 2004, Stas Bekman wrote:
>
> > Joe Schaefer wrote:
> > > Stas Bekman <st...@stason.org> writes:
> > >
> > > [...]
> > >
> > >>OK, but because they are just a few of them and they are small and
> > >>most likely not going to change, may be it's better to dup them in
> > >>apreq to reduce complexity and mess? Later we may come up with some
> > >>better solutions?
> > >
> > >
> > > Sure, I can do that.
> >
> > But please add a comment that eventually this should be
> > resolved and not dupped (e.g. when some other projects may
> > have to deal with the same issue).
> >
> > > I can also prepare a patch of xs/typemap that
> > > replaces the 4 modperl_* symbols with their current definitions
> > >
> > > modperl_hash_tie,
> > > modperl_perl_sv_setref_uv,
> > > modperl_xs_sv2request_rec,
> > > modperl_hash_tied_object,
> > >
> > > which IMO is the simplest of the "simple fixes". Changes to any
> > > of those functions would also require edits to the typemap file,
> > > but that's the only drawback. The upside is that the typemap
> > > is 100% portable.
> >
> > Which delegates the maintenance issues introduces by this
> > change to mp2 developers, which I don't find very exciting
> > :) I was just hoping that Randy will eventually find some
> > magic solution on win32 that will work just like unix does
> > and rendering the whole issue moot.
>
> I'll look at this tonight, but I'm pretty sure what I
> mentioned in an earlier message - linking within apreq2 to
> mp2's aprext static library - will resolve this, and would
> be a relatively minor change to the existing structure in
> both packages.
Randy, I just committed a patch to apreq2's xsbuilder.pl
which overrides the T_HASHOBJ definition to avoid modperl-*
dependence. So apreq2 should test cleanly on Win32 now.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jun 2004, Stas Bekman wrote:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> > [...]
> >
> >>OK, but because they are just a few of them and they are small and
> >>most likely not going to change, may be it's better to dup them in
> >>apreq to reduce complexity and mess? Later we may come up with some
> >>better solutions?
> >
> >
> > Sure, I can do that.
>
> But please add a comment that eventually this should be
> resolved and not dupped (e.g. when some other projects may
> have to deal with the same issue).
>
> > I can also prepare a patch of xs/typemap that
> > replaces the 4 modperl_* symbols with their current definitions
> >
> > modperl_hash_tie,
> > modperl_perl_sv_setref_uv,
> > modperl_xs_sv2request_rec,
> > modperl_hash_tied_object,
> >
> > which IMO is the simplest of the "simple fixes". Changes to any
> > of those functions would also require edits to the typemap file,
> > but that's the only drawback. The upside is that the typemap
> > is 100% portable.
>
> Which delegates the maintenance issues introduces by this
> change to mp2 developers, which I don't find very exciting
> :) I was just hoping that Randy will eventually find some
> magic solution on win32 that will work just like unix does
> and rendering the whole issue moot.
I'll look at this tonight, but I'm pretty sure what I
mentioned in an earlier message - linking within apreq2 to
mp2's aprext static library - will resolve this, and would
be a relatively minor change to the existing structure in
both packages.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>OK, but because they are just a few of them and they are small and
>>most likely not going to change, may be it's better to dup them in
>>apreq to reduce complexity and mess? Later we may come up with some
>>better solutions?
>
>
> Sure, I can do that.
But please add a comment that eventually this should be resolved and not
dupped (e.g. when some other projects may have to deal with the same issue).
> I can also prepare a patch of xs/typemap that
> replaces the 4 modperl_* symbols with their current definitions
>
> modperl_hash_tie,
> modperl_perl_sv_setref_uv,
> modperl_xs_sv2request_rec,
> modperl_hash_tied_object,
>
> which IMO is the simplest of the "simple fixes". Changes to any
> of those functions would also require edits to the typemap file,
> but that's the only drawback. The upside is that the typemap
> is 100% portable.
Which delegates the maintenance issues introduces by this change to mp2
developers, which I don't find very exciting :) I was just hoping that Randy
will eventually find some magic solution on win32 that will work just like
unix does and rendering the whole issue moot.
--
__________________________________________________________________
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: mod_perl.so dependencies in xs/typemap
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> OK, but because they are just a few of them and they are small and
> most likely not going to change, may be it's better to dup them in
> apreq to reduce complexity and mess? Later we may come up with some
> better solutions?
Sure, I can do that. I can also prepare a patch of xs/typemap that
replaces the 4 modperl_* symbols with their current definitions
modperl_hash_tie,
modperl_perl_sv_setref_uv,
modperl_xs_sv2request_rec,
modperl_hash_tied_object,
which IMO is the simplest of the "simple fixes". Changes to any
of those functions would also require edits to the typemap file,
but that's the only drawback. The upside is that the typemap
is 100% portable.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
> [...]
>
>
>>Implementing functions in header files? Is that an acceptable
>>approach? At the moment there are just a few of them, but with time
>>the number may grow.
>
>
> For the typemaps, I'd say yes. In C++ it is accepted practice
> to define short *inline* functions in header files. In C the practice
> is somewhat suspect, because the "inline" semantics aren't always reliable
> (lots of pre-C99 compilers, including gcc [1]). In this circumstance the
> function symbols could wind up as globals, so folks building shared
> libraries might wind up with symbol collisions. However, the vast
> majority of the XS code is for module creation, where symbol collisions
> between modules are a common, managable problem for the OS. In fact,
> AIUI we're already relying on that by providing a few common symbols
> in both mod_perl.so and APR.so.
OK, but because they are just a few of them and they are small and most likely
not going to change, may be it's better to dup them in apreq to reduce
complexity and mess? Later we may come up with some better solutions?
--
__________________________________________________________________
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: mod_perl.so dependencies in xs/typemap
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> Implementing functions in header files? Is that an acceptable
> approach? At the moment there are just a few of them, but with time
> the number may grow.
For the typemaps, I'd say yes. In C++ it is accepted practice
to define short *inline* functions in header files. In C the practice
is somewhat suspect, because the "inline" semantics aren't always reliable
(lots of pre-C99 compilers, including gcc [1]). In this circumstance the
function symbols could wind up as globals, so folks building shared
libraries might wind up with symbol collisions. However, the vast
majority of the XS code is for module creation, where symbol collisions
between modules are a common, managable problem for the OS. In fact,
AIUI we're already relying on that by providing a few common symbols
in both mod_perl.so and APR.so.
> I have a different take on this whole never-ending win32 mess -- since
> 99.99% of win32 users use precompiled packages, may be it's a total
> waste of time and messing up of the code to make things easy to build
> on win32? If there is only one or few people who make binary distros,
> may be they could write a few scripts that will build mp2 and libapreq
> by hardcoding paths, using .o files directly and what not, keeping the
> core simple?
I agree that the keeping the core simple is goodness, and I also note
that the apreq2 typemaps are much worse in this regard. I'm just trying
to find a common approach to this problem that'll work for both projects.
footnotes:
[1] - see http://www.gnu.org/software/gcc/c99status.html
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>As part of the effort to allow APR:: stuff
>>>to work outside of mp2, the xs/typemap file
>>>also needs examination: T_HASHOBJ, T_UVOBJ
>>>both have modperl_ dependencies.
>>
>>I'm not quite following, what kind of deps you are talking about,
>>Joe. e.g. T_HASHOBJ uses modperl_hash_tie which now resides in APR.so
>>and doesn't require mod_perl. Can you give me an example of how this
>>problem can be seen?
>
>
> It'll only manifest in apreq2 on Win32, unless Randy figures out
> how to link Upload.dll against APR.dll.
I guess this is the best solution.
> The problem generally
> occurs when another XS module (not in mp2) tries to use the mp2
> typemaps. On *nix this is no problem because APR.so will provide
> the symbols at runtime, but on systems like Win32, which need the
> location at compile-time, this issue becomes a PITA. Rather than
> hunting APR.lib down, it is very tempting for XS module authors to
> just reimplement those functions themselves. Instead of doing that,
> if mp2 also provided an implementation of those functions through
> a header file, it would eliminate the portability issue.
Implementing functions in header files? Is that an acceptable approach? At the
moment there are just a few of them, but with time the number may grow.
I have a different take on this whole never-ending win32 mess -- since 99.99%
of win32 users use precompiled packages, may be it's a total waste of time and
messing up of the code to make things easy to build on win32? If there is only
one or few people who make binary distros, may be they could write a few
scripts that will build mp2 and libapreq by hardcoding paths, using .o files
directly and what not, keeping the core simple?
But then again, there is AIX which seems to be very similar to win32 when it
comes to linking.
--
__________________________________________________________________
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: mod_perl.so dependencies in xs/typemap
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > As part of the effort to allow APR:: stuff
> > to work outside of mp2, the xs/typemap file
> > also needs examination: T_HASHOBJ, T_UVOBJ
> > both have modperl_ dependencies.
>
> I'm not quite following, what kind of deps you are talking about,
> Joe. e.g. T_HASHOBJ uses modperl_hash_tie which now resides in APR.so
> and doesn't require mod_perl. Can you give me an example of how this
> problem can be seen?
It'll only manifest in apreq2 on Win32, unless Randy figures out
how to link Upload.dll against APR.dll. The problem generally
occurs when another XS module (not in mp2) tries to use the mp2
typemaps. On *nix this is no problem because APR.so will provide
the symbols at runtime, but on systems like Win32, which need the
location at compile-time, this issue becomes a PITA. Rather than
hunting APR.lib down, it is very tempting for XS module authors to
just reimplement those functions themselves. Instead of doing that,
if mp2 also provided an implementation of those functions through
a header file, it would eliminate the portability issue.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl.so dependencies in xs/typemap
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> As part of the effort to allow APR:: stuff
> to work outside of mp2, the xs/typemap file
> also needs examination: T_HASHOBJ, T_UVOBJ
> both have modperl_ dependencies.
I'm not quite following, what kind of deps you are talking about, Joe. e.g.
T_HASHOBJ uses modperl_hash_tie which now resides in APR.so and doesn't
require mod_perl. Can you give me an example of how this problem can be seen?
--
__________________________________________________________________
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