httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: [mp2 patch] getting APR to work w/o modperl
Date Sun, 16 May 2004 20:23:44 GMT
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?

> 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

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. This could be resolved in some cases by linking APR::*
against the relevant modperl_xxx.o files; however, for those
that require some functionality within itself, there
might be a problem ...

> > The only alternative I was able
> > to come up with is to use LoadLibrary/GetProcAddress
> > to set a function pointer to that of a function
> > within a dll. I tried to cut this down to the
> > minimal needed, and came up with something along
> > the lines of, generically,
> >
> > typdef ... /* delare the function pointers */
> >
> > HINSTANCE hlib;
> > if (GetProcAddresses(&hlib, "Some.dll",
> >                      &fn_1, "func_1",
> >                      &fn_2, "func_2",
> >                      ...) {
> >   /* the functions are available */
> > }
> > if (hlib != NULL) FreeLibrary(hlib);
> >
> > where GetProcAddresses() is a simple (generic) routine that
> > associates, from Some.dll, func_1, func_2, ... with fn_1,
> > fn_2, ... So, in this approach, for each APR::* as
> > appropriate, necessary function pointers must be declared,
> > GetProcAddresses() is invoked, and finally, if necessary,
> > FreeLibrary() called at the end.
> >
> > However, I don't have enough experience with the build
> > system to compare if the above would be easier or harder to
> > set up and maintain, compared to linking against the
> > appropriate .so files.
> The biggest problem I see here, is that we won't be able
> to test whether things still work on windows, every time
> we change or add something. So I'd prefer not to use it.
> If this can be done automatically, without touching the
> existing code, then i guess it's OK. But I'm not quite
> sure this is possible.

That's certainly a concern ... If this is ever
attempted, I think some (most?) of it could be
done somewhat automatically, but maybe it'd be
better to explore the above approach first.

best regards,

View raw message