You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Niko Tyni <nt...@debian.org> on 2014/08/07 13:50:45 UTC
t/apr-ext failures at gcc -O0
Hi,
we're seeing t/apr-ext failures when building without optimization on
current Debian unstable (Apache 2.4.10, Perl 5.18.2). An example is
t/apr-ext/base64.t ...................... Can't load '/home/niko/tmp/libapache2-mod-perl2/blib/arch/auto/APR/APR.so' for module APR: /home/niko/tmp/libapache2-mod-perl2/blib/arch/auto/APR/APR.so: undefined symbol: perl_module at /usr/lib/perl/5.18/DynaLoader.pm line 184.
at /home/niko/tmp/libapache2-mod-perl2/blib/lib/APR/Base64.pm line 23.
Compilation failed in require at /home/niko/tmp/libapache2-mod-perl2/blib/lib/APR/Base64.pm line 23.
BEGIN failed--compilation aborted at /home/niko/tmp/libapache2-mod-perl2/blib/lib/APR/Base64.pm line 23.
Compilation failed in require at /home/niko/tmp/libapache2-mod-perl2/t/lib/TestAPRlib/base64.pm line 12.
BEGIN failed--compilation aborted at /home/niko/tmp/libapache2-mod-perl2/t/lib/TestAPRlib/base64.pm line 12.
Compilation failed in require at t/apr-ext/base64.t line 8.
BEGIN failed--compilation aborted at t/apr-ext/base64.t line 8.
t/apr-ext/base64.t ...................... Dubious, test returned 2 (wstat 512, 0x200)
No subtests run
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.
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).
--
Niko Tyni ntyni@debian.org
Re: t/apr-ext failures at gcc -O0
Posted by Steve Hay <st...@googlemail.com>.
On 13 August 2014 09:16, Steve Hay <st...@googlemail.com> wrote:
> On 7 August 2014 12:50, Niko Tyni <nt...@debian.org> wrote:
>> 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.
Now applied in revision 1617722.
>
> 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.)
And also now done in revision 1617727.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: t/apr-ext failures at gcc -O0
Posted by Steve Hay <st...@googlemail.com>.
On 7 August 2014 12:50, Niko Tyni <nt...@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