Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of Farid_Zaripov@epam.com
 designates 217.21.63.3 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Intel C++ build issues on Windows
Date: Mon, 2 Jul 2007 21:08:39 +0300
Message-ID: <7BDB2168BEAEF14C98F1901FD2DE64389D7445@epmsa009.minsk.epam.com>
In-Reply-To: <4685550B.8050503@roguewave.com>
Thread-Topic: Intel C++ build issues on Windows
Thread-Index: Ace6fotj/LJKHBljSxiDAEHqyOsmuQCSPQMA
References: <4685352A.2020104@roguewave.com> <46854951.8000509@roguewave.com>
 <4685550B.8050503@roguewave.com>
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <stdcxx-dev@incubator.apache.org>

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]=20
> Sent: Friday, June 29, 2007 9:53 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>=20
> Andrew Black wrote:
> > Greetings Martin
> >=20
> > It appears that the build that started on 6/27 entered a hang state=20
> > due to an undismissed dialog.  The utility used to=20
> automatically close=20
> > dialogs was failing for some reason, and the team=20
> responsible for the=20
> > automated build system has been working on resolving it.
>=20
> I see. I thought we cleaned them all up. Farid, are there any=20
> more tests or examples that you're aware of that could be=20
> causing this?
> I suppose it's always possible that a test will crash and pop=20
> up a window on the screen (what a pain!) We really need to=20
> come up with a reliable way to prevent this.

  There are 3 types of popup's:
1) Dr.Watson window, appear on access violation or unhandled exception;
2) CRT asserts and parameter validat

>=20
> >=20
> > The other two builds that started last night have completed, though=20
> > are reporting back in a ERROR state.
>=20
> So they are. The config header or log aren't available, even=20
> though it looks like they were successfully created. There=20
> might be useful information in there. Are they not getting=20
> saved in the database?
> And if not, is there a way to save them?
>=20
> Since Farid says he can't reproduce it in his environment=20
> there must be a difference between ours and his.
>=20
> Farid, what is the exact version of Intel C++ and MSVC that=20
> you're using on Windows? Our logs indicate we are at 9.1.028=20
> for icl and Visual Studio 2005. Andrew, do you know if we're=20
> have a service pack installed for Visual Studio and if so,=20
> what version it is?
> Ditto for the OS.

Intel Compiler:
-------------
Intel(R) C++ Compiler for 32-bit applications, Version 9.1    Build
20060323Z
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.
-------------

Intel Compiler Integration:
-------------
Intel(R) C++ Compiler Integration for Microsoft Visual Studio 2005,
Version 9.1.590.2005 ,
Copyright (C) 2002-2006 Intel Corporation.
-------------

> Farid, is there a way to determine the exact versions=20
> (including patches or service packs) of theses things on=20
> Windows? If there is, would it be possible to enhance the=20
> Windows infrastructure to write all this information out=20
> somewhere? E.g., as the first step of the configuration=20
> process where we currently say (something like):
>=20
>    Configuring for icc-9.1 - 12d Optimized Thread-safe Dll
>=20
> It would be useful to enhance this to give more detail, e.g.,
>=20
>    Configuring for icc-9.1.028 (Visual Studion 2005, Service
>    Pack X) - 12d Optimized Thread-safe Dll on Windows 2000,
>    Service Pack Y.

  Good idea. I will try to deal with it.

Farid.