Jan Kaluža wrote on 2013-07-17: > On 07/16/2013 03:04 PM, Steve Hay wrote: > The difference is that Apache2/Const/Const.dll now depends on > mod_perl.so (it didn't use to), and that isn't in a location in the > PATH when running the test suite. >> >> Using dumpbin /imports to see why we have this new dependency shows > that it's due to the 'perl_module' symbol... We've been here before > recently with the APR::Brigade build failure. I wondered if > Apache2::Const (and maybe others) needed to link against libaprext.lib > (with its fake 'perl_module' symbol) to avoid this problem, but > lib/ModPerl/BuildMM says: >> >> # in order to decouple APR/APR::* from mod_perl.so, # link >> these modules against the static MP_APR_LIB lib, # rather than >> the mod_perl lib (which would demand mod_perl.so # be >> available). For other modules, use mod_perl.lib as # usual. >> which suggests that Apache2::* modules are expected to depend on > mod_perl.so (even though this one happened not to until now), so using > libaprext.lib instead of mod_perl.lib here is probably the wrong thing > to do here and would likely break things that require a proper > definitions of 'perl_module'. >> >> So I think the answer is to add src/modules/perl (where mod_perl.so has >> been built) to the PATH when running the test suite. >> >> If I do that manually in my Command Prompt window then "nmake test" > runs normally (albeit with a *lot* of test failures [1] which I'll > look at later), but I'm not sure where is the best place to make that > happen automatically within Apache-Test? >> >> Is this an issue on other OSes, or only on Windows? (Not sure if you >> normally build mod_perl dynamically or statically linked elsewhere?) > > If I understand it right, we don't link modules to anything explicitly > on Linux, but when they are loaded later, all their dependencies have > to be loaded on runtime too. Since apr/apr-util and mod_perl are > loaded by httpd, there's no problem. > > At least I see "LIBS => q[ ]" in MakeMaker parametrs for Apache2::* > modules. >
Ok. We definitely need to link against apr/apr-util and mod_perl libs on Windows to resolve symbols at link time, and that creates a demand for the corresponding DLLs (actually called .so rather than .dll) at run time. All Apache2::* modules' DLLs have always been linked against the apr/apr-util and mod_perl libs (see ModPerl::BuildMM::WriteMakefile() -- isn't that used on other OSes too, though?), but the linker drops the dependency if no symbols are actually imported from them so in the past Apache2/Const/Const.dll didn't demand mod_perl.so at run time because it hadn't imported anything from it. That's changed now, so I think I need to slip src/modules/perl into the PATH for testing. But I'm still puzzled why the demand to load mod_perl.so isn't already met, though, because httpd.exe must have already loaded it when it saw the LoadModule line in the conf file, which must be before anything mentions Apache2::Const. Httpd.exe, as you say, finds and loads mod_perl.so without problem (the LoadModule line in the test conf file contains a full path to it, for a start), so Apache2::Const's demand for it should just be a no-op, it being loaded already... I will continue to investigate that before looking at changing Apache-Test. I wonder if something is using Apache2::Const too soon? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
