You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/08/02 19:09:13 UTC
current test failures
I haven't run my nightly builds in a while, but I get the following failures
against 2.0.46 at the moment:
t/apr-ext/table.........................ok 42/52/perl/perl-5.8.4/bin/perl:
relocation error:
/src/mod_perl-2.0/blib/arch/Apache2/auto/APR/Table/Table.so: undefined
symbol: apr_table_compress
t/api/request_rec.t has a handful of failures but looks like it is
autogenerated, which may be the cause of the error - right now it's under
cvs control so it may be out of date.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
>> t/api/request_rec.t has a handful of failures but looks like it is
>> autogenerated, which may be the cause of the error - right now it's under
>> cvs control so it may be out of date.
>
>
> Yes, it's no longer autogenerated. You didn't check the output of 'cvs
> up', you had collisions which you needed to resolve by removing
> t/api/request_rec.t
>
> a better approach is to run t/TEST -clean before running 'cvs up'.
Actually I think it's not the collision, but t/TEST -clean removing the
newly checked out file. So:
t/TEST -clean
cvs up t/api/request_rec.t
should do the trick :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>>> /* added in APACHE_2_0_47/APR_0_9_4 */
>>> void apr_table_compress(apr_table_t *t, unsigned flags);
>>
>>
>>
>> Ah, this is a _15 showstopper, we need to cut out the broken support
>> for 2.0.46, make it 2.0.47, and document that. At the moment it just
>> won't compile with 2.0.46.
>>
>> Geoff, what was the XXX for 0_46 in the code/tests to clean things up?
>
>
> I've fixed Makefile.PL to require 2.0.47 and I've checked the rest, so
> it looks that we are good on this part.
yeah, sorry. I guess I removed the 2.0.46-specific code and other bumps but
forgot to address the Makefile.PL. sorry.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
>> /* added in APACHE_2_0_47/APR_0_9_4 */
>> void apr_table_compress(apr_table_t *t, unsigned flags);
>
>
> Ah, this is a _15 showstopper, we need to cut out the broken support for
> 2.0.46, make it 2.0.47, and document that. At the moment it just won't
> compile with 2.0.46.
>
> Geoff, what was the XXX for 0_46 in the code/tests to clean things up?
I've fixed Makefile.PL to require 2.0.47 and I've checked the rest, so it
looks that we are good on this part. It's just that I can't test with
2.0.47, as it won't start for me.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> ah, now it's clear. it's implemented in 2.0.47, right?
>>> Hmm, 2.0.47 was released a year ago. Do you think we may be should just
>>> drop 2.0.46? I wonder how many 2.0.46 users are out there. Poll the
>>> list?
>>
>>
>>
>> I'm for dropping back to 2.0.47 outright in the next release. IIRC
>> libapreq
>> requires at least 2.0.47 so we're not alone. poll the user list (not the
>> dev list ;) and you'll get 1001 different opinions :)
>
>
> right.
>
>>> If not we need to add the C compat layer object to the APR.so linking,
>>> which shouldn't be too hard to do.
>>
>>
>>
>> sure, if we don't solve it via 2.0.47.
>
>
> looks like it's the case:
>
> /* added in APACHE_2_0_47/APR_0_9_4 */
> void apr_table_compress(apr_table_t *t, unsigned flags);
Ah, this is a _15 showstopper, we need to cut out the broken support for
2.0.46, make it 2.0.47, and document that. At the moment it just won't
compile with 2.0.46.
Geoff, what was the XXX for 0_46 in the code/tests to clean things up?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>ah, now it's clear. it's implemented in 2.0.47, right?
>>Hmm, 2.0.47 was released a year ago. Do you think we may be should just
>>drop 2.0.46? I wonder how many 2.0.46 users are out there. Poll the list?
>
>
> I'm for dropping back to 2.0.47 outright in the next release. IIRC libapreq
> requires at least 2.0.47 so we're not alone. poll the user list (not the
> dev list ;) and you'll get 1001 different opinions :)
right.
>>If not we need to add the C compat layer object to the APR.so linking,
>>which shouldn't be too hard to do.
>
>
> sure, if we don't solve it via 2.0.47.
looks like it's the case:
/* added in APACHE_2_0_47/APR_0_9_4 */
void apr_table_compress(apr_table_t *t, unsigned flags);
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> ah, now it's clear. it's implemented in 2.0.47, right?
> Hmm, 2.0.47 was released a year ago. Do you think we may be should just
> drop 2.0.46? I wonder how many 2.0.46 users are out there. Poll the list?
I'm for dropping back to 2.0.47 outright in the next release. IIRC libapreq
requires at least 2.0.47 so we're not alone. poll the user list (not the
dev list ;) and you'll get 1001 different opinions :)
>
> If not we need to add the C compat layer object to the APR.so linking,
> which shouldn't be too hard to do.
sure, if we don't solve it via 2.0.47.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Geoffrey Young wrote:
>>
>>
>>>I haven't run my nightly builds in a while, but I get the following
>>>failures
>>>against 2.0.46 at the moment:
>>>
>>>t/apr-ext/table.........................ok
>>>42/52/perl/perl-5.8.4/bin/perl:
>>>relocation error:
>>>/src/mod_perl-2.0/blib/arch/Apache2/auto/APR/Table/Table.so: undefined
>>>symbol: apr_table_compress
>>
>>
>>That sounds familiar. We provide the backcompat layer for that function,
>>remember? I think you added it. :)
>
>
> yes, I remember. IIRC it is in modperl_apache_compat, but only so that I
> can use apr_table_compress in mod_perl internally. the proper solution here
> is to only support apr_table_compress in APR if APR itself supports it. I'm
> not familiar enough with what you guys are doing in the separation process
> to know how to go about that.
ah, now it's clear. it's implemented in 2.0.47, right?
Hmm, 2.0.47 was released a year ago. Do you think we may be should just
drop 2.0.46? I wonder how many 2.0.46 users are out there. Poll the list?
If not we need to add the C compat layer object to the APR.so linking,
which shouldn't be too hard to do.
>>> t/api/request_rec.t has a handful of failures but looks like it is
>>>autogenerated, which may be the cause of the error - right now it's under
>>>cvs control so it may be out of date.
>>
>>
>>Yes, it's no longer autogenerated. You didn't check the output of 'cvs
>>up', you had collisions which you needed to resolve by removing
>>t/api/request_rec.t
>
>
> yes, I saw the collisions, and I removed the file. your other suggestion
> made things work. thanks.
Excellent!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> I haven't run my nightly builds in a while, but I get the following
>> failures
>> against 2.0.46 at the moment:
>>
>> t/apr-ext/table.........................ok
>> 42/52/perl/perl-5.8.4/bin/perl:
>> relocation error:
>> /src/mod_perl-2.0/blib/arch/Apache2/auto/APR/Table/Table.so: undefined
>> symbol: apr_table_compress
>
>
> That sounds familiar. We provide the backcompat layer for that function,
> remember? I think you added it. :)
yes, I remember. IIRC it is in modperl_apache_compat, but only so that I
can use apr_table_compress in mod_perl internally. the proper solution here
is to only support apr_table_compress in APR if APR itself supports it. I'm
not familiar enough with what you guys are doing in the separation process
to know how to go about that.
>
>> t/api/request_rec.t has a handful of failures but looks like it is
>> autogenerated, which may be the cause of the error - right now it's under
>> cvs control so it may be out of date.
>
>
> Yes, it's no longer autogenerated. You didn't check the output of 'cvs
> up', you had collisions which you needed to resolve by removing
> t/api/request_rec.t
yes, I saw the collisions, and I removed the file. your other suggestion
made things work. thanks.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: current test failures
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> I haven't run my nightly builds in a while, but I get the following failures
> against 2.0.46 at the moment:
>
> t/apr-ext/table.........................ok 42/52/perl/perl-5.8.4/bin/perl:
> relocation error:
> /src/mod_perl-2.0/blib/arch/Apache2/auto/APR/Table/Table.so: undefined
> symbol: apr_table_compress
That sounds familiar. We provide the backcompat layer for that function,
remember? I think you added it. :)
> t/api/request_rec.t has a handful of failures but looks like it is
> autogenerated, which may be the cause of the error - right now it's under
> cvs control so it may be out of date.
Yes, it's no longer autogenerated. You didn't check the output of 'cvs
up', you had collisions which you needed to resolve by removing
t/api/request_rec.t
a better approach is to run t/TEST -clean before running 'cvs up'.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org