perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <>
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
> (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, # link
>>          these modules against the static MP_APR_LIB lib, # rather than
>>          the mod_perl lib (which would demand # be
>>          available). For other modules, use mod_perl.lib as # usual.
>> which suggests that Apache2::* modules are expected to depend on
> (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 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 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 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
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:
For additional commands, e-mail:
View raw message