perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve....@verosoftware.com>
Subject RE: [httpd24 branch] merge with trunk?
Date Wed, 17 Jul 2013 08:36:38 GMT
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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Mime
View raw message