[mp2] static vs dynamic Win32 build

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: [mp2] static vs dynamic Win32 build

[Stas Bekman <st...@stason.org>]

Randy Kobes wrote:
> 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 ...

It's not so perfect to have different components on different platforms. 
Ideally it should be the same thing everywhere. On the other hand making 
things harder and may be a bit less efficient on all platforms because of one 
platform is not worth the maintenance gain. On the other hand AIX will 
probably have the same issues, as win32, so we may need to do the same there.

So, Randy, please take up whichever you think is the best route for win32 
users, for now doing it specifically for the win32 case, leaving the rest as 
it is. I think I prefer the "static" solution, since it requires no changes on 
the users side. And a new .dll is going to be a pain to support, for those who 
won't use prepackaged build.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org