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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
