You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/03/21 11:03:54 UTC
Re: svn commit: r387468 - /apr/apr/branches/1.2.x/test/Makefile.in
Joe,
If you are going to reintroduce this breakage on darwin, would you mind
porting your clever solution we managed to agree on, at least? Ping-pong'ing
between platform failures just isn't cool.
I note this behavior is not present in APR 0.9 - so tests are currently
failing for RH Linux on APR 0.9? Forgive all my confusion, but this is why
I had determined your original change on the 1.x branches was improper.
Bill
jorton@apache.org wrote:
> Author: jorton
> Date: Tue Mar 21 01:30:39 2006
> New Revision: 387468
>
> URL: http://svn.apache.org/viewcvs?rev=387468&view=rev
> Log:
> Revert vetoed r384716, fixing testall regression e.g. when using
> ccache.
>
> Modified:
> apr/apr/branches/1.2.x/test/Makefile.in
>
> Modified: apr/apr/branches/1.2.x/test/Makefile.in
> URL: http://svn.apache.org/viewcvs/apr/apr/branches/1.2.x/test/Makefile.in?rev=387468&r1=387467&r2=387468&view=diff
> ==============================================================================
> --- apr/apr/branches/1.2.x/test/Makefile.in (original)
> +++ apr/apr/branches/1.2.x/test/Makefile.in Tue Mar 21 01:30:39 2006
> @@ -37,9 +37,9 @@
> INCDIR=../include
> INCLUDES=-I$(INCDIR) -I$(srcdir)/../include
>
> -# uses libtool wrapper scripts which ensures we are testing the currently built
> -# library in ../.libs/, not the installed/stale flavor due to -rpath.
> -LINK_PROG = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) $(ALL_LDFLAGS) -o $@
> +# link programs using -no-install to get real executables not
> +# libtool wrapper scripts which link an executable when first run.
> +LINK_PROG = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) -no-install $(ALL_LDFLAGS) -o $@
>
> check: $(STDTEST_PORTABLE) $(STDTEST_NONPORTABLE)
> for prog in $(STDTEST_PORTABLE) $(STDTEST_NONPORTABLE); do \
Re: svn commit: r387468 - /apr/apr/branches/1.2.x/test/Makefile.in
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Tue, Mar 21, 2006 at 04:03:54AM -0600, William Rowe wrote:
>
>> If you are going to reintroduce this breakage on darwin, would you mind
>>porting your clever solution we managed to agree on, at least?
>>Ping-pong'ing
>>between platform failures just isn't cool.
>
> If you want to backport the clever stuff please go ahead, but I'm happy
> to stick with simple regression-fixes on the branches.
Provided they solve your bugs, irrespective of who else's bugs they cause ;-?
>> I note this behavior is not present in APR 0.9 - so tests are currently
>>failing for RH Linux on APR 0.9? Forgive all my confusion, but this is why
>>I had determined your original change on the 1.x branches was improper.
>
> The failure is not specific to some "RH Linux", I've seen it fail on
> Solarises too. I can't remember seeing 0.9.x trigger this failure,
> maybe it does though.
Well I'd be very interested to know. Since your environment seems to be good
at triggering your issue, would you report back? If you are asking me to fix
the breakage for 1.2 that your commit 64765 introduced - it seems worth fixing
the whole thing on both platforms, consistently.
Re: svn commit: r387468 - /apr/apr/branches/1.2.x/test/Makefile.in
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Tue, Mar 21, 2006 at 04:03:54AM -0600, William Rowe wrote:
>
>> If you are going to reintroduce this breakage on darwin, would you mind
>>porting your clever solution we managed to agree on, at least?
>>Ping-pong'ing
>>between platform failures just isn't cool.
>
> If you want to backport the clever stuff please go ahead, but I'm happy
> to stick with simple regression-fixes on the branches.
Provided they solve your bugs, irrespective of who else's bugs they cause ;-?
>> I note this behavior is not present in APR 0.9 - so tests are currently
>>failing for RH Linux on APR 0.9? Forgive all my confusion, but this is why
>>I had determined your original change on the 1.x branches was improper.
>
> The failure is not specific to some "RH Linux", I've seen it fail on
> Solarises too. I can't remember seeing 0.9.x trigger this failure,
> maybe it does though.
Well I'd be very interested to know. Since your environment seems to be good
at triggering your issue, would you report back? If you are asking me to fix
the breakage for 1.2 that your commit 64765 introduced - it seems worth fixing
the whole thing on both platforms, consistently.
Re: svn commit: r387468 - /apr/apr/branches/1.2.x/test/Makefile.in
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Mar 21, 2006 at 04:03:54AM -0600, William Rowe wrote:
> If you are going to reintroduce this breakage on darwin, would you mind
> porting your clever solution we managed to agree on, at least?
> Ping-pong'ing
> between platform failures just isn't cool.
If you want to backport the clever stuff please go ahead, but I'm happy
to stick with simple regression-fixes on the branches.
> I note this behavior is not present in APR 0.9 - so tests are currently
> failing for RH Linux on APR 0.9? Forgive all my confusion, but this is why
> I had determined your original change on the 1.x branches was improper.
The failure is not specific to some "RH Linux", I've seen it fail on
Solarises too. I can't remember seeing 0.9.x trigger this failure,
maybe it does though.
Regards,
joe
Re: svn commit: r387468 - /apr/apr/branches/1.2.x/test/Makefile.in
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Mar 21, 2006 at 04:03:54AM -0600, William Rowe wrote:
> If you are going to reintroduce this breakage on darwin, would you mind
> porting your clever solution we managed to agree on, at least?
> Ping-pong'ing
> between platform failures just isn't cool.
If you want to backport the clever stuff please go ahead, but I'm happy
to stick with simple regression-fixes on the branches.
> I note this behavior is not present in APR 0.9 - so tests are currently
> failing for RH Linux on APR 0.9? Forgive all my confusion, but this is why
> I had determined your original change on the 1.x branches was improper.
The failure is not specific to some "RH Linux", I've seen it fail on
Solarises too. I can't remember seeing 0.9.x trigger this failure,
maybe it does though.
Regards,
joe