Mailing List Archive: t/apr-ext failures at gcc -O0

t/apr-ext failures at gcc -O0

Aug 7, 2014, 4:50 AM

Post #1 of 3 (1658 views)

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 [ In reply to ]

steve.m.hay at googlemail

Aug 13, 2014, 1:16 AM

Post #2 of 3 (1596 views)

Permalink

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

Re: t/apr-ext failures at gcc -O0 [ In reply to ]

steve.m.hay at googlemail

Aug 13, 2014, 6:13 AM

Post #3 of 3 (1594 views)

Permalink

On 13 August 2014 09:16, Steve Hay <steve.m.hay@googlemail.com> wrote:
> On 7 August 2014 12:50, Niko Tyni <ntyni@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

Mailing List Archive

Mailing List Archive

Attached Files: