Re: Windows build failures
Greetings all. As I mentioned earlier, I reloaded the nightly testing archives earlier to recover from a failed glue script update. Most builds have re-run at this point, so I'm going to try to annotate the list based on what I'm seeing in the nightly testing system at the moment. These results (or updated versions) will be exported tomorrow, though I'm going on vacation for a couple days, so I'm trying to send this out before I go. Martin Sebor wrote: > We continue to be having serious problems in our latest results > due to what looks like infrastructure or setup issues (we had no > updates over the weekend due to a ssh permission issue I ran > into last Friday). I isolated the problematic results into the > attached page to make it easier to focus on them. Below is > a digest summarizing the problems from the logs. > > Andrew, Farid: have you made any progress on these? > > win_2000-4-x86 > All builds still in DATA state. This includes MSVC 7.1 and Intel > C++ 9.1 and 10.0. See STDCXX-543. The state of these builds has improved, as the Intel builds are now only lacking the test suite results, rather than all results as had been the case before (due to compiler sanity check failures) > win_*-em64t, msvc-8.0, 12D-win32 > All locale tests fail with exit status of 4. This includes all > versions of Windows, including 2003, XP, and Vista. This appears to have been resolved. We are still seeing several locale tests terminate with an exit status of 4, but these failures appear to be consistent with other build types. > > win_xp-1-em64t, icl-10.0, {12D,15S}-win32 > win_xp-2-x86, icl-9.1 > Library fails to build with "Cannot access data for the desired > file since it is in a zombie state." Resolved on XP em64t, not resolved for XP x86. I'm not certain if it's a case of http://svn.apache.org/viewvc?rev=575000&view=rev not being included in the archive, or if there is a subtle issue in the changes for icl-9.1. > > win_xp-2-x86, msvc-8.0, 12d-win32 > Build fails at: > > checking system > architectured:\bman5\builds\34027456\source-buildspace\etc\config\windows\configure.wsf(342, > 10) Microsoft JScript runtime error: Permission denied > Project : error PRJ0019: A tool returned an error code from "Performing > Custom Build Step" > Resolved. --Andrew Black
Re: Windows build failures
Martin Sebor wrote: > Farid Zaripov wrote: >>> -Original Message- >>> From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, >>> September 11, 2007 10:01 PM >>> To: stdcxx-dev@incubator.apache.org >>> Subject: Re: Windows build failures >> >>> Andrew, Farid: have you made any progress on these? >>> >>> win_2000-4-x86 >>>All builds still in DATA state. This includes MSVC 7.1 and Intel >>>C++ 9.1 and 10.0. >> >> As I sad I think the problem in very long command line. I'll manage >> this problem by extending exec utility to support passing the programs >> list through file. > > Ah, yes. I had a conversation with Andrew about this last week > and we agreed that this was going to be the way to proceed. > Somehow, making it happen or at least opening an issue for it > slipped through the cracks. You created an issue for it Martin: https://issues.apache.org/jira/browse/STDCXX-543 > >> >>> win_*-em64t, msvc-8.0, 12D-win32 >>>All locale tests fail with exit status of 4. This includes all >>>versions of Windows, including 2003, XP, and Vista. >> >>> win_xp-1-em64t, icl-10.0, {12D,15S}-win32 win_xp-2-x86, icl-9.1 >>>Library fails to build with "Cannot access data for the desired >>>file since it is in a zombie state." >> >> Possibly the problem caused by that both ICC 9.1 and ICC 10.0 >> installed on the same machine. I think my current patch will help. >> http://svn.apache.org/viewvc?rev=575000&view=rev > > Andrew, please keep an eye on this and if the patch doesn't do > it help Farid figure out what's causing this. Hopefully we'll get a fairly quick turnaround on this. I blotched a change to the windows glue scripts yesterday, which I've fixed, and I am in the process of rebuilding archives to get it into nightly testing. I think Farid's change made it into the archive, but I'm not certain. --Andrew Black
Re: Windows build failures
Martin Sebor wrote: Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 10:01 PM To: stdcxx-dev@incubator.apache.org Subject: Re: Windows build failures Andrew, Farid: have you made any progress on these? win_2000-4-x86 All builds still in DATA state. This includes MSVC 7.1 and Intel C++ 9.1 and 10.0. As I sad I think the problem in very long command line. I'll manage this problem by extending exec utility to support passing the programs list through file. Ah, yes. I had a conversation with Andrew about this last week and we agreed that this was going to be the way to proceed. Somehow, making it happen or at least opening an issue for it slipped through the cracks. Actually, I take it back. I did open an issue: https://issues.apache.org/jira/browse/STDCXX-543 Martin
Re: Windows build failures
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 11, 2007 10:01 PM To: stdcxx-dev@incubator.apache.org Subject: Re: Windows build failures Andrew, Farid: have you made any progress on these? win_2000-4-x86 All builds still in DATA state. This includes MSVC 7.1 and Intel C++ 9.1 and 10.0. As I sad I think the problem in very long command line. I'll manage this problem by extending exec utility to support passing the programs list through file. Ah, yes. I had a conversation with Andrew about this last week and we agreed that this was going to be the way to proceed. Somehow, making it happen or at least opening an issue for it slipped through the cracks. win_*-em64t, msvc-8.0, 12D-win32 All locale tests fail with exit status of 4. This includes all versions of Windows, including 2003, XP, and Vista. win_xp-1-em64t, icl-10.0, {12D,15S}-win32 win_xp-2-x86, icl-9.1 Library fails to build with "Cannot access data for the desired file since it is in a zombie state." Possibly the problem caused by that both ICC 9.1 and ICC 10.0 installed on the same machine. I think my current patch will help. http://svn.apache.org/viewvc?rev=575000&view=rev Andrew, please keep an eye on this and if the patch doesn't do it help Farid figure out what's causing this. Martin win_xp-2-x86, msvc-8.0, 12d-win32 Build fails at: checking system architectured:\bman5\builds\34027456\source-buildspace\etc\con fig\windows\configure.wsf(342, 10) Microsoft JScript runtime error: Permission denied Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step" RemoveFile("arch.exe") function failed after invoking it. I will add the wait-loop if this problem will persistent. Farid.
RE: Windows build failures
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 11, 2007 10:01 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Windows build failures > Andrew, Farid: have you made any progress on these? > > win_2000-4-x86 >All builds still in DATA state. This includes MSVC 7.1 and Intel >C++ 9.1 and 10.0. As I sad I think the problem in very long command line. I'll manage this problem by extending exec utility to support passing the programs list through file. > win_*-em64t, msvc-8.0, 12D-win32 >All locale tests fail with exit status of 4. This includes all >versions of Windows, including 2003, XP, and Vista. > win_xp-1-em64t, icl-10.0, {12D,15S}-win32 win_xp-2-x86, icl-9.1 >Library fails to build with "Cannot access data for the desired >file since it is in a zombie state." Possibly the problem caused by that both ICC 9.1 and ICC 10.0 installed on the same machine. I think my current patch will help. http://svn.apache.org/viewvc?rev=575000&view=rev > > win_xp-2-x86, msvc-8.0, 12d-win32 >Build fails at: > >checking system > architectured:\bman5\builds\34027456\source-buildspace\etc\con > fig\windows\configure.wsf(342, > 10) Microsoft JScript runtime error: Permission denied > Project : error PRJ0019: A tool returned an error code from > "Performing Custom Build Step" RemoveFile("arch.exe") function failed after invoking it. I will add the wait-loop if this problem will persistent. Farid.
Re: Windows build failures
We continue to be having serious problems in our latest results due to what looks like infrastructure or setup issues (we had no updates over the weekend due to a ssh permission issue I ran into last Friday). I isolated the problematic results into the attached page to make it easier to focus on them. Below is a digest summarizing the problems from the logs. Andrew, Farid: have you made any progress on these? win_2000-4-x86 All builds still in DATA state. This includes MSVC 7.1 and Intel C++ 9.1 and 10.0. win_*-em64t, msvc-8.0, 12D-win32 All locale tests fail with exit status of 4. This includes all versions of Windows, including 2003, XP, and Vista. win_xp-1-em64t, icl-10.0, {12D,15S}-win32 win_xp-2-x86, icl-9.1 Library fails to build with "Cannot access data for the desired file since it is in a zombie state." win_xp-2-x86, msvc-8.0, 12d-win32 Build fails at: checking system architectured:\bman5\builds\34027456\source-buildspace\etc\config\windows\configure.wsf(342, 10) Microsoft JScript runtime error: Permission denied Project : error PRJ0019: A tool returned an error code from "Performing Custom Build Step" Andrew Black wrote: Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 8:28 PM To: stdcxx-dev@incubator.apache.org Subject: Windows build failures What is the status of the Windows builds on trunk? There still are a large number of severe failures that need to be resolved for the 4.2 release: win_2000-4-x86 icl-10.0all The command call "%ICPP_COMPILER10%\IA32\Bin\iclvars.bat" failed with error: "The system cannot find the path specified." win_2000-4-x86 icl-9.1 all The command call "%ICPP_COMPILER91%\IA32\Bin\iclvars.bat" failed with error: "The system cannot find the path specified." Is needed to check whether that path valid or not. Andrew, can you chek this? Greetings Farid The iclvars.bat scripts are being used to set up the environment from a theoretically empty state. In particular, the command 'call setenv icl-10.0' results in call "C:\Program Files\Intel\Compiler\C++\10.0.026\IA32\Bin\iclvars.bat" and the command 'call setenv icl-9.1' results in call "C:\Program Files\Intel\Compiler\C++\9.1\IA32\Bin\iclvars.bat" . Both of the calls to setenv (a pesky batch script) are made near the beginning of the build process. --Andrew Black
Re: Windows build failures
Farid Zaripov wrote: >> -Original Message- >> From: Martin Sebor [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, September 04, 2007 8:28 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Windows build failures >> >> What is the status of the Windows builds on trunk? There >> still are a large number of severe failures that need to be >> resolved for the 4.2 release: >> >> win_2000-4-x86 icl-10.0all > The command call "%ICPP_COMPILER10%\IA32\Bin\iclvars.bat" failed with > error: > "The system cannot find the path specified." > >> win_2000-4-x86 icl-9.1 all > The command call "%ICPP_COMPILER91%\IA32\Bin\iclvars.bat" failed with > error: > "The system cannot find the path specified." > > Is needed to check whether that path valid or not. Andrew, can you > chek this? Greetings Farid The iclvars.bat scripts are being used to set up the environment from a theoretically empty state. In particular, the command 'call setenv icl-10.0' results in call "C:\Program Files\Intel\Compiler\C++\10.0.026\IA32\Bin\iclvars.bat" and the command 'call setenv icl-9.1' results in call "C:\Program Files\Intel\Compiler\C++\9.1\IA32\Bin\iclvars.bat" . Both of the calls to setenv (a pesky batch script) are made near the beginning of the build process. --Andrew Black
RE: Windows build failures
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 04, 2007 8:28 PM > To: stdcxx-dev@incubator.apache.org > Subject: Windows build failures > > What is the status of the Windows builds on trunk? There > still are a large number of severe failures that need to be > resolved for the 4.2 release: > > win_2000-4-x86icl-10.0all The command call "%ICPP_COMPILER10%\IA32\Bin\iclvars.bat" failed with error: "The system cannot find the path specified." > win_2000-4-x86icl-9.1 all The command call "%ICPP_COMPILER91%\IA32\Bin\iclvars.bat" failed with error: "The system cannot find the path specified." Is needed to check whether that path valid or not. Andrew, can you chek this? > win_2000-4-x86msvc-7.1all The tests did not invoked. I think that maximum command line length was exceeded. The Windows 2000 command line limited by MAX_PATH value (MAX_PATH == 260). We need to add the ability to pass files list into exec utility using external file, i.e.: exec.exe [OPTIONS] @files.lst >From MSDN (function CreateProcess): - lpCommandLine [in, out] Pointer to a null-terminated string that specifies the command line to execute. The maximum length of this string is 32K characters. Windows 2000: The maximum length of this string is MAX_PATH characters. - > win_2003-1-x86msvc-7.111s Seems to be ok for now... > win_xp-1-em64ticl-10.012D-win32 > win_xp-1-em64ticl-10.012d-win32 > win_xp-2-x86 icl-10.08s > win_xp-2-x86 icl-9.1 all The "build.wsf(163, 14) (null): Invalid pointer" error. Trying to fix thus: http://svn.apache.org/viewvc?rev=573012&view=rev Farid.
Re: Windows build failures reported as DATA
Greetings Martin. I've done a little digging, and the problem appears to originate in the glue scripts used for nightly testing. In particular, the post-run parser for windows incorrectly interprets a failure to build the library as a hard (state C) failure, rather than a library (state F) failure. I will be checking in a fix shortly. --Andrew Black Martin Sebor wrote: > Most of our Windows buils failed due to a change I committed over > the weekend (http://svn.apache.org/viewvc?view=rev&revision=554281). > I'm working on fixing the regression but the breakage highlighted > another problem that I'm hoping you might be able to quickly fix, > Andrew. Even though the builds failed due to a compilation error > in the library they are reported in the status of DATA instead > of LIB. > > Thanks > Martin