perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve.m....@googlemail.com>
Subject Re: t/apr-ext failures at gcc -O0
Date Wed, 13 Aug 2014 08:16:49 GMT
On 7 August 2014 12:50, Niko Tyni <ntyni@debian.org> wrote:
> Hi,
>
> we're seeing t/apr-ext failures when building without optimization on
> current Debian unstable (Apache 2.4.10, Perl 5.18.2).
>
> It looks like APR.so can only be loaded from inside mod_perl:
>
>  % perl -Iblib/lib -Iblib/arch -MAPR -e1
>  Can't load 'blib/arch/auto/APR/APR.so' for module APR: blib/arch/auto/APR/APR.so: undefined
symbol: perl_module
> at /usr/lib/perl/5.18/DynaLoader.pm line 184.
>   at -e line 0.
>  Compilation failed in require.
>  BEGIN failed--compilation aborted.

Yes, I think that's correct/normal.


>
> The problem comes from src/modules/perl/modperl_apache_includes.h:
>
>  #if !defined(MP_IN_XS) && AP_MODULE_MAGIC_AT_LEAST(20100606, 0)
>  APLOG_USE_MODULE(perl);
>  #endif
>
> where APLOG_USE_MODULE(perl) expands via /usr/include/apache2/http_config.h to
>
>  extern module perl_module; static int * const aplog_module_index = &(perl_module.module_index);
>
> At -O2, this is optimized away when it's not used, but -O0 keeps it.
>
> The MP_IN_XS guard looks promising; defining that for the APR (and
> APR/PerlIO) build seems to help.  I was able to get the test suite pass
> at both -O0 and -O2 with the attached patch.
>
> It seems possible that other parts of xs/ are affected too but aren't
> exercised by the test suite.
>
> The history of MP_IN_XS usage is just
>
>  http://svn.apache.org/viewvc?view=revision&revision=1410295
>  http://svn.apache.org/viewvc?view=revision&revision=68792
>
> but it looks like a "correct" solution to me. Does that make sense?
>
> I'm attaching a patch that modifies the Makefile.PL files accordingly.
> I expect there are other ways to accomplish the same thing too.
>
> This is also https://bugs.debian.org/756989 (cc'd).
> --

Thanks, I will apply this later today after more testing.

I think the same trick in xs/APR/aprext will also save modperl_dummy.c
from needing to include a dummy perl_module too :-) I.e.
http://svn.apache.org/viewvc?view=revision&revision=1502392 can
largely be undone, with the appropriate MP_IN_XS magic in aprext's
Makefile.PL too (and it looks like APR/Const also needs it). (The
dummy file is still needed for other symbols too, though -- see
http://svn.apache.org/viewvc?view=revision&revision=1538006. I don't
know of any other way around that, though.)

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


Mime
View raw message