httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2 patch] getting APR to work w/o modperl
Date Mon, 17 May 2004 00:44:06 GMT
On Sun, 16 May 2004, Randy Kobes wrote:

> On Sat, 15 May 2004, Stas Bekman wrote:
> > Randy Kobes wrote:
> > > On Mon, 10 May 2004, Stas Bekman wrote:
> > >
> > >>How about a quick workaround as follows: For windows only,
> > >>link statically with all APR/Foo.o and the required
> > >>modperl_foo.o and arrange for the bootstrap not to call it
> > >>for windows if is loaded?
> > >
> > >
> > > That sounds good ...
> >
> > So can you try to tackle that? I guess my latest patch
> > won't apply against the current cvs and I'll need to
> > re-sync it and resolve collisions.
> I'll give it a go ... So as I'll be current, could you
> re-sync it, if it's not too difficult? Alternatively,
> if the patch is OK on others (apart from Win32, and
> perhaps aix), is it ready to apply, and we'll work
> from there?

Well, I don't want to destabilize the tree, we should make a new release 
pretty soon. I think while you are playing with various solutions you 
could just check the cvs tree for the day I've posted my second patch and 
it should apply just fine. Your work is going to be in the xs/APR/APR 
area, not really touching anything else. If you think it's a problem I'll 
then try to post an up-to-date patch, but it may quickly become 
out-of-date in a few days.
> > I guess all you need to do is to change
> > xs/APR/APR/Makefile.PL to collect all .o files from under
> > xs/APR and a few selected src/modules/perl/modperl_xxx.o
> > and link them statically with if under win32. (and
> > may be some other platforms too (aix comes to mind)).
> Just so I understand correctly, in this approach we'll have
> one (big) that has collected all the functionality of
> the individual APR::* modules (as well as the old
> itself and selected symbols from modperl_xxx.o)? Or does APR
> stay essentially the same (with the added symbols from
> selected modperl_xxx.o), and then one links each APR::* with

I was talking about the former, where will include all 
objects in Wrap/APR/*/.o (not .so) and some 
of src/modules/perl/modperl_xxx.o.

I'm not sure how can you go with the latter idea. I mean, I'll work 
perfectly fine without mod_perl. But how is it going to work under 
mod_perl, when both and will have the same symbols, and 
according to your suggestion, both will be loaded (since APR/ will 
be linked against It would have worked perfectly if we could also 
link against and not include those symbols in Which is probably the best solution possible. The problem is 
that the loaded will somehow have to find when trying to load This could have been done by installing along with I suppose.

In that case we will have APR a totally autonomous systems and mod_perl 
will use it. May be it makes perfect sense, but I haven't thought of the 
implications for users.

> It should be relatively straightforward to do the latter (as
> long as is built before APR::*). However, with the
> former, there'd be problems building the individual APR::*
> modules first, to be used as components in building,
> for the same reason that exists now - to build APR::*, one
> has to specify the library where the symbols are found, and
> one can't specify a library ( that hasn't been built
> yet.

But I was talking about building .o objects, not shared libs. and linking 
those .o objects with Will that be a problem too? AFAIK you never 
need to provide information about shared libs, during compilation time. Is 
that different on windows?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message