RE: 22.locale.codecvt.out test failure
Martin Sebor wrote: > >Travis Vitek wrote: >> >> >> Martin Sebor wrote: >>> Travis Vitek wrote: I'm absolutely certain it worked in the recent past, but >I'll go back and do a build to make sure I'm not totally insane. >>> You don't need to. Do a search among the older build logs >>> under http://stdcxx.apache.org/builds/4.2.x/logs/ instead. >>> Here's a recent list: >>> >>> linux_suse-10.0-em64t-gcc-4.1.0-12D-654664-log.gz.txt >>> linux_suse-10.0-em64t-gcc-4.1.0-12D-655584-log.gz.txt >>> linux_suse-10.0-em64t-gcc-4.1.0-12D-656010-log.gz.txt >> >> [...] >> >> AFAIK, this doesn't do me much good unless I can guess the >revision used >> to do a build on a given platform. How am I to browse the list of old >> build logs? > >They're all in > > people.apache.org:/www/stdcxx.apache.org/builds/*/logs/ > >To get the listing I sent, run: > > ssh people.apache.org \ >" cd /www/stdcxx.apache.org/builds/4.2.x/logs \ > && ls linux_suse-10.0-em64t-gcc-4.1.0-12D-*-log.gz.txt" > Thanks. The location was the thing that I was missing. I didn't realize that stdcxx.apache.org was hosted on people.apache.org. Regardless, I don't see any build results that are old enough to show me what I need. I pulled tags/4.2.1 and did a build on AIX. After looking at the results I noticed the problem (maybe everyone else noticed it already). The test 22.locale.codecvt is a new test and didn't exist at the time STDCXX-650 was closed. >Martin >
Re: 22.locale.codecvt.out test failure
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: I'm absolutely certain it worked in the recent past, but I'll go back and do a build to make sure I'm not totally insane. You don't need to. Do a search among the older build logs under http://stdcxx.apache.org/builds/4.2.x/logs/ instead. Here's a recent list: linux_suse-10.0-em64t-gcc-4.1.0-12D-654664-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-655584-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-656010-log.gz.txt [...] AFAIK, this doesn't do me much good unless I can guess the revision used to do a build on a given platform. How am I to browse the list of old build logs? They're all in people.apache.org:/www/stdcxx.apache.org/builds/*/logs/ To get the listing I sent, run: ssh people.apache.org \ " cd /www/stdcxx.apache.org/builds/4.2.x/logs \ && ls linux_suse-10.0-em64t-gcc-4.1.0-12D-*-log.gz.txt" Martin
RE: 22.locale.codecvt.out test failure
Martin Sebor wrote: >Travis Vitek wrote: >> >> I'm absolutely certain it worked in the recent past, but I'll go back >> and do a build to make sure I'm not totally insane. >> > >You don't need to. Do a search among the older build logs >under http://stdcxx.apache.org/builds/4.2.x/logs/ instead. >Here's a recent list: > >linux_suse-10.0-em64t-gcc-4.1.0-12D-654664-log.gz.txt >linux_suse-10.0-em64t-gcc-4.1.0-12D-655584-log.gz.txt >linux_suse-10.0-em64t-gcc-4.1.0-12D-656010-log.gz.txt [...] AFAIK, this doesn't do me much good unless I can guess the revision used to do a build on a given platform. How am I to browse the list of old build logs?
Re: 22.locale.codecvt.out test failure
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: If this is true, we might want to change the exec utility (which does the redirection) to send the output of tests somewhere else. Sure, that is one option. But that doesn't answer my question. Why is this failing now, after it worked in the past. See https://issues.apache.org/jira/browse/STDCXX-650 Dunno. Maybe it never did work correctly and I missed it when closing the issue. I'm absolutely certain it worked in the recent past, but I'll go back and do a build to make sure I'm not totally insane. You don't need to. Do a search among the older build logs under http://stdcxx.apache.org/builds/4.2.x/logs/ instead. Here's a recent list: linux_suse-10.0-em64t-gcc-4.1.0-12D-654664-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-655584-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-656010-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-656444-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-656916-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-657235-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-658487-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-658917-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-659278-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-659601-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-660336-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-660492-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-661152-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-661910-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-662101-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-662614-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-663410-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-664236-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-665796-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-666829-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-668819-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-669747-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-670084-log.gz.txt linux_suse-10.0-em64t-gcc-4.1.0-12D-670734-log.gz.txt
RE: 22.locale.codecvt.out test failure
>Martin Sebor wrote: >Travis Vitek wrote: >> Martin Sebor wrote: >> >>> If this is true, we might want to change >>> the exec utility (which does the redirection) to send the output of >>> tests somewhere else. >>> >> >> Sure, that is one option. But that doesn't answer my question. Why is >> this failing now, after it worked in the past. See >> >> https://issues.apache.org/jira/browse/STDCXX-650 > >Dunno. Maybe it never did work correctly and I missed it when >closing the issue. I'm absolutely certain it worked in the recent past, but I'll go back and do a build to make sure I'm not totally insane.
Re: 22.locale.codecvt.out test failure
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
The named test fails on all platforms with an EXEC error. It
looks like
the problem is that when trying to build the executable
'22.locale.codecvt.out', it actually generates an output file for the
test '22.locale.codecvt', which is obviously not going to be
executable.
[...]
I know this worked at one time because I was involved in the
discussion for fixing this problem the last time it came up
[http://tinyurl.com/5nv7qx].
Any ideas why this problem is back to haunt us?
There are two tests with similar names:
22.locale.codecvt and 22.locale.codecvt.out
I suspect that when 22.locale.codecvt runs, its output is redirected
to 22.locale.codecvt.out.
Is there an echo in here? :)
Oh yeah, you said that. Sorry, I missed that bit in your post.
If this is true, we might want to change
the exec utility (which does the redirection) to send the output of
tests somewhere else.
Sure, that is one option. But that doesn't answer my question. Why is
this failing now, after it worked in the past. See
https://issues.apache.org/jira/browse/STDCXX-650
Dunno. Maybe it never did work correctly and I missed it when
closing the issue.
Now my new question is, why change the output file extension? It seems
that would have a better chance of causing additional failures.
Now you didn't read what I said carefully enough ;-) I didn't
suggest changing [just] the file extension, or say to what it
should be changed. One option might be to redirect the output
to a file named something like ${TMPDIR:-/tmp}/$prefix.out.$$
where prefix might be the name of the test program.
Martin
RE: 22.locale.codecvt.out test failure
Martin Sebor wrote: > >Travis Vitek wrote: >> The named test fails on all platforms with an EXEC error. It >> looks like >> the problem is that when trying to build the executable >> '22.locale.codecvt.out', it actually generates an output file for the >> test '22.locale.codecvt', which is obviously not going to be >> executable. >> [...] >> >> I know this worked at one time because I was involved in the >> discussion for fixing this problem the last time it came up >> [http://tinyurl.com/5nv7qx]. >> >> Any ideas why this problem is back to haunt us? > >There are two tests with similar names: > > 22.locale.codecvt and 22.locale.codecvt.out > >I suspect that when 22.locale.codecvt runs, its output is redirected >to 22.locale.codecvt.out. Is there an echo in here? :) >If this is true, we might want to change >the exec utility (which does the redirection) to send the output of >tests somewhere else. > Sure, that is one option. But that doesn't answer my question. Why is this failing now, after it worked in the past. See https://issues.apache.org/jira/browse/STDCXX-650 Now my new question is, why change the output file extension? It seems that would have a better chance of causing additional failures. >Martin >
Re: 22.locale.codecvt.out test failure
Travis Vitek wrote: The named test fails on all platforms with an EXEC error. It looks like the problem is that when trying to build the executable '22.locale.codecvt.out', it actually generates an output file for the test '22.locale.codecvt', which is obviously not going to be executable. $ gmake 22.locale.codecvt.out gcc -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -I/amd/devco/vitek/stdcxx/trunk/include -I/build/vitek/5.0.0/11S/include -I/amd/devco/vitek/stdcxx/trunk/tests/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.codecvt.cpp gcc 22.locale.codecvt.o -o 22.locale.codecvt -L/build/vitek/5.0.0/11S/rwtest -lrwtest11S -L/build/vitek/5.0.0/11S/lib -lstd11S -lsupc++ -lm LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/vitek/5.0.0/11S/lib ./22.locale.codecvt >22.locale.codecvt.out 2>&1 I know this worked at one time because I was involved in the discussion for fixing this problem the last time it came up [http://tinyurl.com/5nv7qx]. Any ideas why this problem is back to haunt us? There are two tests with similar names: 22.locale.codecvt and 22.locale.codecvt.out I suspect that when 22.locale.codecvt runs, its output is redirected to 22.locale.codecvt.out. If this is true, we might want to change the exec utility (which does the redirection) to send the output of tests somewhere else. Martin
RE: 22.locale.codecvt.out test failure
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 25, 2008 5:26 PM > To: dev@stdcxx.apache.org > Subject: 22.locale.codecvt.out test failure > > > The named test fails on all platforms with an EXEC error. It > looks like > the problem is that when trying to build the executable > '22.locale.codecvt.out', it actually generates an output file for the > test '22.locale.codecvt', which is obviously not going to be > executable. > > $ gmake 22.locale.codecvt.out > gcc -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG > -I/amd/devco/vitek/stdcxx/trunk/include > -I/build/vitek/5.0.0/11S/include > -I/amd/devco/vitek/stdcxx/trunk/tests/include -pedantic > -nostdinc++ -g > -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long > -Wcast-align > /amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.codecvt.cpp > gcc 22.locale.codecvt.o -o 22.locale.codecvt > -L/build/vitek/5.0.0/11S/rwtest -lrwtest11S > -L/build/vitek/5.0.0/11S/lib -lstd11S -lsupc++ -lm > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/vitek/5.0.0/11S/lib > ./22.locale.codecvt >22.locale.codecvt.out 2>&1 > > I know this worked at one time because I was involved in the > discussion > for fixing this problem the last time it came up > [http://tinyurl.com/5nv7qx]. > > Any ideas why this problem is back to haunt us? My guess would be a suffix rule for *.out files. Somehow the suffix rule is pulling in 22.locale.codecvt which IIRC is a completely different test. Brad.
