Mailing List Archive

Compile errors with SVN revision 1733039 for unthreaded perl
Hi,

I'm looking into upgrading our perl version to 5.22.1. Since mod_perl
2.0.9 doen't work with 5.22, I thought that it would be a good idea to
test the SVN version of mod_perl.

We compile our own perl, and we compile it without ithread support,
which the new env-support doesn't appear to work with. I get the
following compile errors:

modperl_env.c: In function 'modperl_env_init':
modperl_env.c:657:10: error: 'my_perl' undeclared (first use in this
function)
modperl_env.c:657:10: note: each undeclared identifier is reported only
once for each function it appears in
modperl_env.c: In function 'modperl_env_unload':
modperl_env.c:688:10: error: 'my_perl' undeclared (first use in this
function)

As far as I can tell, this is because pTHX expands to define a my_perl
parameter for modperl_env_init and modperl_env_unload if perl is
compiled with ithreads support. However without ithreads support pTHX
expands to nothing, causing the compile error.

To fix this, I've tried to simply delete the if (!my_perl) tests in
modperl_env_init and modperl_env_unload. I'm fairly sure that this is
safe to do for modperl_env_unload, since it is only called from
modperl_perl_destruct, which appears to have a perl interpreter
instance. However I'm not so sure for modperl_env_init.

Removing those two if-statements reveal that we should call
modperl_env_unload with aTHX as the parameter in modperl_perl_descruct,
so that the number of arguments is correct both with and without ithread
support enabled.

The attached patch makes both changes. Apply with -p0.

I've tested this against our "home-compiled" perl 5.22 where it now
compiles and passes the tests. I've also tried against the Ubuntu 12.04
supplied perl with ithreads support, which also compiles and passes all
the tests.

--
Klaus S. Madsen, Udvikler, ksm@jobindex.dk
Jobindex A/S, Holger Danskes Vej 91, 2000 Frederiksberg
Tlf +45 38 32 33 55, Dir +45 38 32 33 70
http://www.jobindex.dk/
Re: Compile errors with SVN revision 1733039 for unthreaded perl [ In reply to ]
Sorry,

A small correction. The test works with a "home compiled" perl 5.16.3
without ithreads support. With 5.22.1 without ithreads support I run
into the same issue that r1702395 should have solved with sprintf warnings.

While I'm no expert in this, I believe that the comment in r1702395 is
wrong. It's not because of the thread context that the number of
arguments is wrong, it's because of the way WrapXS.pm handles functions
with variable parameter length (i.e. ... functions).

In the .xs code items is the number of elements in the MARK array.
However when WrapXS.pm generates code for a ... function, it will
increment MARK, so that it points to the second argument to the
function. It will not, however decrement items, which means that items
and MARK now are out of sync. I suspect that MARK is incremented to skip
the object that the function is called on.

I've attached a simple patch that updates the comment and removes the
ifdef around the decrementation of items, which solves the test-failures
for non-threaded perl 5.22.

Klaus S. Madsen, Udvikler, ksm@jobindex.dk
Jobindex A/S, Holger Danskes Vej 91, 2000 Frederiksberg
Tlf +45 38 32 33 55, Dir +45 38 32 33 70
http://www.jobindex.dk/

On 2016-03-02 11:15, Klaus S. Madsen wrote:
> Hi,
>
> I'm looking into upgrading our perl version to 5.22.1. Since mod_perl
> 2.0.9 doen't work with 5.22, I thought that it would be a good idea to
> test the SVN version of mod_perl.
>
> We compile our own perl, and we compile it without ithread support,
> which the new env-support doesn't appear to work with. I get the
> following compile errors:
>
> modperl_env.c: In function 'modperl_env_init':
> modperl_env.c:657:10: error: 'my_perl' undeclared (first use in this
> function)
> modperl_env.c:657:10: note: each undeclared identifier is reported
> only once for each function it appears in
> modperl_env.c: In function 'modperl_env_unload':
> modperl_env.c:688:10: error: 'my_perl' undeclared (first use in this
> function)
>
> As far as I can tell, this is because pTHX expands to define a my_perl
> parameter for modperl_env_init and modperl_env_unload if perl is
> compiled with ithreads support. However without ithreads support pTHX
> expands to nothing, causing the compile error.
>
> To fix this, I've tried to simply delete the if (!my_perl) tests in
> modperl_env_init and modperl_env_unload. I'm fairly sure that this is
> safe to do for modperl_env_unload, since it is only called from
> modperl_perl_destruct, which appears to have a perl interpreter
> instance. However I'm not so sure for modperl_env_init.
>
> Removing those two if-statements reveal that we should call
> modperl_env_unload with aTHX as the parameter in
> modperl_perl_descruct, so that the number of arguments is correct both
> with and without ithread support enabled.
>
> The attached patch makes both changes. Apply with -p0.
>
> I've tested this against our "home-compiled" perl 5.22 where it now
> compiles and passes the tests. I've also tried against the Ubuntu
> 12.04 supplied perl with ithreads support, which also compiles and
> passes all the tests.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
Re: Compile errors with SVN revision 1733039 for unthreaded perl [ In reply to ]
On 2 March 2016 at 10:15, Klaus S. Madsen <ksm@jobindex.dk> wrote:
> Hi,
>
> I'm looking into upgrading our perl version to 5.22.1. Since mod_perl 2.0.9
> doen't work with 5.22, I thought that it would be a good idea to test the
> SVN version of mod_perl.
>
> We compile our own perl, and we compile it without ithread support, which
> the new env-support doesn't appear to work with. I get the following compile
> errors:
>
> modperl_env.c: In function 'modperl_env_init':
> modperl_env.c:657:10: error: 'my_perl' undeclared (first use in this
> function)
> modperl_env.c:657:10: note: each undeclared identifier is reported only once
> for each function it appears in
> modperl_env.c: In function 'modperl_env_unload':
> modperl_env.c:688:10: error: 'my_perl' undeclared (first use in this
> function)
>
> As far as I can tell, this is because pTHX expands to define a my_perl
> parameter for modperl_env_init and modperl_env_unload if perl is compiled
> with ithreads support. However without ithreads support pTHX expands to
> nothing, causing the compile error.
>
> To fix this, I've tried to simply delete the if (!my_perl) tests in
> modperl_env_init and modperl_env_unload. I'm fairly sure that this is safe
> to do for modperl_env_unload, since it is only called from
> modperl_perl_destruct, which appears to have a perl interpreter instance.
> However I'm not so sure for modperl_env_init.
>
> Removing those two if-statements reveal that we should call
> modperl_env_unload with aTHX as the parameter in modperl_perl_descruct, so
> that the number of arguments is correct both with and without ithread
> support enabled.
>
> The attached patch makes both changes. Apply with -p0.
>
> I've tested this against our "home-compiled" perl 5.22 where it now compiles
> and passes the tests. I've also tried against the Ubuntu 12.04 supplied perl
> with ithreads support, which also compiles and passes all the tests.
>

Thanks, committed in r1733563.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Compile errors with SVN revision 1733039 for unthreaded perl [ In reply to ]
On 2 March 2016 at 15:35, Klaus S. Madsen <ksm@jobindex.dk> wrote:
> Sorry,
>
> A small correction. The test works with a "home compiled" perl 5.16.3
> without ithreads support. With 5.22.1 without ithreads support I run into
> the same issue that r1702395 should have solved with sprintf warnings.
>
> While I'm no expert in this, I believe that the comment in r1702395 is
> wrong. It's not because of the thread context that the number of arguments
> is wrong, it's because of the way WrapXS.pm handles functions with variable
> parameter length (i.e. ... functions).
>
> In the .xs code items is the number of elements in the MARK array. However
> when WrapXS.pm generates code for a ... function, it will increment MARK, so
> that it points to the second argument to the function. It will not, however
> decrement items, which means that items and MARK now are out of sync. I
> suspect that MARK is incremented to skip the object that the function is
> called on.
>
> I've attached a simple patch that updates the comment and removes the ifdef
> around the decrementation of items, which solves the test-failures for
> non-threaded perl 5.22.
>

Thanks, committed in r1733564.

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