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 Wed, 19 May 2004 13:42:32 GMT
On Tue, 18 May 2004, Stas Bekman wrote:

> Randy Kobes wrote:
> > On Mon, 17 May 2004, Stas Bekman wrote:
> > [ ... ]
> >
> >>Randy Kobes wrote:
> >>
> >>>I'll try it for Windows and see how much is involved; if
> >>>this works as expected, it should just involve changing
> >>>how things are compiled, as well as the order ( coming
> >>>first). But one of the joys of working with Windows is
> >>>that things are never as expected ;)
> >
> >
> > I've now tried it on Windows, and in particular the
> > (patched) apr-ext tests pass. This though was manual;
> Great!
> > I'll next try to get things built automatically. But
> > just for information, what was required was
> > - adjust xs/APR/APR/APR.def to include
> >     modperl_interp_unselect
> >     modperl_hash_tie
> >     modperl_hash_tied_object
> >     modperl_perl_gensym
> >     modperl_error_strerror
> > in the list of exported symbols
> We ought to automate that. I think you've missed symbols,
> like tracing functions, since you didn't build with
> tracing enabled or because the APR/Foo.o's that my patch
> tests don't use tracing. We should probably look at the
> the apache/apr DECLARE macros. Alternatively it can be a
> common group of files modperl_common_*.c but it'll be hard
> to extract those symbol names.  Another approach is to
> split the tables/ModPerl/ (which I think
> that's how .def is generated now). May be the function
> names should have a different prefix than /modperl_/. In
> which case it'll be clear that they are common ones.

No doubt I did miss some symbols - this was just a quick
thing to see in particular if the apr-ext tests worked.
I'll look at the - you're right that this
is used to generate the .def file now.

> > - build APR first, so APR::* can link against it (the
> > default action is to build APR::* first);
> Really? Is it specific to win32? On linux with the current
> cvs, I can run 'make -j' which builds things in parallel
> and I was getting APR/*.so getting build while
> src/modules/perl/ was still not built. But I
> don't see problem with arranging what you did.

Without building APR first, APR::* dies at the link stage
about references to unknown symbols. I couldn't see the
nmake equivalent to 'make -j', but I'll look - this must
be a common problem.

> > - adjust the Makefiles in APR::* to link to
> >      blib/arch/Apache2/auto/APR/APR.lib
> > before linking to src/modules/perl/mod_perl.lib
> Good.
> > - add
> >      blib/arch/Apache2/auto/APR/
> > to the PATH, so APR.dll can be found (perhaps APR.dll
> > [] should be installed to $APACHE2/lib or
> > $APACHE2/bin, as appropriate?)
> That's not good. The whole idea was not to create a
> library which will need to be searched by the loader. The
> ideas was to have a plain .so which will live under perl's
> lib, and loading any APR/ will first load,
> and then APR/ So yes, there is a need to change the
> autogenerated APR/*.pm files, but you shouldn't need to
> mess with PATH or anything that has to do with system-wide
> loader.
> If we were to create a separate .so (read: win32/dll),
> that would be since all these things in
> modperl_common.* have nothing to do with apr. But we want
> to avoid to impose that added enormous complexity on our
> users.

This fiddling with the PATH was just to get the tests
working (one could also use a LoadFile "...APR.dll"
directive to accomplish the same thing). There's probably
some internal way to do that within APR::*, along the
lines of loading within APR/, so that users
don't have to be bothered.

> > In any case, no source code changes were needed - I think
> > all the above can be done within the Makefile generation.
> It's fine to change the source if it's needed :)
> Good work, Randy!

Thanks :)

best regards,

View raw message