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 Mon, 17 May 2004 03:47:39 GMT
On Sun, 16 May 2004, Stas Bekman wrote:

> On Sun, 16 May 2004, Randy Kobes wrote:
[ .. ]
> 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.

Sounds good ...

> > > 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.

OK, that makes sense ...

> 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

In this approach I don't there's a problem on Windows with
linking against libraries with the same symbols; depending
on the order of the libraries in the link command, VC++
will resolve the symbols not found in the object files in
the 1st library file it finds that has them (which then
registers the corresponding .so, if it's a shared library),
so any identical symbols in a later library used in the link
command are ignored. Thus, you could in principle build
an application linked against two dlls that have the
same symbols in them and there shouldn't be a conflict,
as the application knows, from how it was linked, which
dll each symbol comes from.

However, this also means that no symbols can be resolved
through mod_perl.lib, as this would require loading (unless one used the -delayload link option,
to load the dll only if a symbol is invoked).

> 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?

No, you're right - resolving all symbols only is required at
link time, so this could be done by just compiling (with -c)
the APR::* files to build the object files, and skip
building the associated APR::* dlls, as is done now.

I think things are becoming clearer to me - thanks.
It looks like most of this can be done by fiddling
with the compiling/linking commands, without the need
(hopefully) of any source code modifications. I'll
try it and see.

best regards,

View raw message