Assuming something like Joe's patch is applied in the
current cvs in defining modperl_interp_unselect, I've been
working on getting the Win32 build sorted out. One problem
with the way the current build is set up - compiling the
needed symbols into APR.dll - on Win32 is that, as far as I
can see, APR.dll must be loaded as a dll, even with the 'use
APR ();' statements in the APR::* modules. The most
straightforward way for this is to add the directory APR.dll
lives in to the PATH, but this isn't so great from a user's
perspective. I've been playing with two alternatives, and
was wondering if anyone had any thoughts.

Both approaches involve making an "external" library (say,
aprext) out of the src/modules/perl/*.c files now compiled
into APR.dll. One can do this in two ways:

- dynamic (ie, make an aprext.dll). This has the usual
shared library advantages, but then one has to care about
the PATH again when trying to load it (or use a Win32
function LoadLibrary() to load the dll, but then one
has to know the path to where aprext.dll lives).

- static. The libs that link against it will be larger, but
not that bad, as there's not that many symbols in it.

Right now I'm more inclined to favour the static approach,
as it's simpler (which is a bigger factor in something as
complex as mod_perl), and thus less prone to problems (eg,
users moving the dll, or mixing up versions, as can happen
with any external dll). However, this somewhat goes against
a big part of the philosophy of mp2 as being lean, so I
could persuaded to go the dynamic route ...

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to