You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/06/29 18:36:58 UTC
Intel C++ build issues on Windows
The Windows 2000 Intel C++ 9.1 builds have been in WAIT state
since 6/27. Andrew, in case you missed my note from last night,
can you please look and see what the problem is?
The same builds on Windows 2003 all failed with the error below.
Farid, if you're not already investigating it can you please do
so?
Thanks
Martin
Compiling stdcxx library...
D:\bman5\builds\33780929\source-buildspace\etc\config\windows\build.wsf(163,
14) (null): Invalid pointer
Summary log was generated in
file://D:/bman5/builds/33780929/source-buildspace/build/icc-9.1-11s.html
build complete
Re: Intel C++ build issues on Windows
Posted by Andrew Black <ab...@roguewave.com>.
Greetings Martin
According to the IT department, we have version 9.1.037 installed on one
build server on each platform. Intel builds on windows are generally
broken, due to a poorly coordinated installation of the 10.0.026
compiler. I will be working to resolve these issues on Monday.
--Andrew Black
Martin Sebor wrote:
> Farid Zaripov wrote:
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:sebor@roguewave.com] Sent: Friday, June
>>> 29, 2007 9:53 PM
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: Intel C++ build issues on Windows
>>>
> [...]
>>> Farid, what is the exact version of Intel C++ and MSVC that you're
>>> using on Windows? Our logs indicate we are at 9.1.028 for icl and
>>> Visual Studio 2005. Andrew, do you know if we're have a service pack
>>> installed for Visual Studio and if so, what version it is?
>>> Ditto for the OS.
>>
>> Intel Compiler:
>> -------------
>> Intel(R) C++ Compiler for 32-bit applications, Version 9.1 Build
>> 20060323Z
>
> The latest 9.1 patch is 9.1.038 dated 2007/05/10. We appear
> to be at 9.1.028, which is quite a bit out of date (dated
> 2006/07/06). Yours is even older and corresponds to 9.1.022.
>
> I think we all need to upgrade to the latest patch and see
> if the issue persists.
>
> Martin
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Friday, June 29, 2007 9:53 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Intel C++ build issues on Windows
>>
[...]
>> Farid, what is the exact version of Intel C++ and MSVC that
>> you're using on Windows? Our logs indicate we are at 9.1.028
>> for icl and Visual Studio 2005. Andrew, do you know if we're
>> have a service pack installed for Visual Studio and if so,
>> what version it is?
>> Ditto for the OS.
>
> Intel Compiler:
> -------------
> Intel(R) C++ Compiler for 32-bit applications, Version 9.1 Build
> 20060323Z
The latest 9.1 patch is 9.1.038 dated 2007/05/10. We appear
to be at 9.1.028, which is quite a bit out of date (dated
2006/07/06). Yours is even older and corresponds to 9.1.022.
I think we all need to upgrade to the latest patch and see
if the issue persists.
Martin
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Wednesday, July 18, 2007 7:47 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>
> Another option is to rig one of the library headers (e.g.,
> _config.h) to optionally #include some header that we could
> then "insert" by defining the right magic macro. Like this:
>
> // _defs.h
> #ifdef _RWSTD_INCLUDE_HEADER
> # include _RWSTD_INCLUDE_HEADER
> #endif
>
> then we'de compile our examples with the following option on
> the command line:
> -D_RWSTD_INCLUDE_HEADER=examples/include/include.h
Personally, I prefer this option.
Farid.
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Monday, July 09, 2007 9:54 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Intel C++ build issues on Windows
>>
>>> I can make the function i.e. init_example() in which all needed
>>> hooks are installed, but this function should be invoked
>> from main()
>>> in all examples.
>> I was hoping to do it in a non-intrusive way. For instance,
>> on UNIX we could link with (or preload) a shared library that
>> would in its startup code run the function. Or we could use a
>> command line option to the preprocessor (such as gcc -include
>> <file>) to include a header containing the definition of such
>> a function:
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Preprocessor-Optio
>> ns.html#index-include-634
>>
>> Does MSVC have something similar?
>
> Yes. The MSVC have /FI option:
> -------
> Causes the preprocessor to process the specified header file.
That's good. Now we just need to look to see if all the other
compilers support something like it. Unfortunately, the first
two I looked at don't seem to have anything resembling it.
HP aCC:
http://docs.hp.com/en/8759/options.htm#preproc
Sun C++:
http://developers.sun.com/sunstudio/documentation/ss12/opts/index.html
So it looks like we need something different.
One possibility might be to create a copy of a standard file,
say <cstddef>, in examples/include and have it do what examples.h
does now in addition to #including the real <cstddef>. And of
course, we'd have to remember to explicitly #include <cstddef>
in every example to make it work.
Another option is to rig one of the library headers (e.g.,
_config.h) to optionally #include some header that we could
then "insert" by defining the right magic macro. Like this:
// _defs.h
#ifdef _RWSTD_INCLUDE_HEADER
# include _RWSTD_INCLUDE_HEADER
#endif
then we'de compile our examples with the following option on
the command line:
-D_RWSTD_INCLUDE_HEADER=examples/include/include.h
Neither of these is very pretty but we have a feature request
for something pretty close to the second one:
http://issues.apache.org/jira/browse/STDCXX-288
(We could do what Markus suggested with examples.h and have
the header #include config.h at the top.)
Thoughts?
Martin
>
>
> /FI[ ]pathname
>
>
> Remarks
> This option has the same effect as specifying the file with double
> quotation marks in an #include directive on the first line of every
> source file specified on the command line, in the CL environment
> variable, or in a command file. If you use multiple /FI options, files
> are included in the order they are processed by CL.
> -------
>
> Farid.
>
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Monday, July 09, 2007 9:54 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>
> > I can make the function i.e. init_example() in which all needed
> > hooks are installed, but this function should be invoked
> from main()
> > in all examples.
>
> I was hoping to do it in a non-intrusive way. For instance,
> on UNIX we could link with (or preload) a shared library that
> would in its startup code run the function. Or we could use a
> command line option to the preprocessor (such as gcc -include
> <file>) to include a header containing the definition of such
> a function:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Preprocessor-Optio
> ns.html#index-include-634
>
> Does MSVC have something similar?
Yes. The MSVC have /FI option:
-------
Causes the preprocessor to process the specified header file.
/FI[ ]pathname
Remarks
This option has the same effect as specifying the file with double
quotation marks in an #include directive on the first line of every
source file specified on the command line, in the CL environment
variable, or in a command file. If you use multiple /FI options, files
are included in the order they are processed by CL.
-------
Farid.
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Monday, July 09, 2007 7:44 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Intel C++ build issues on Windows
>>
>>>> We'll also need a solution for those executables (but we can worry
>>>> about that once we're done enhancing the test driver).
>>> We can install the similar handlers in each example, but I don't
>>> see any 2) of 3) popups in examples at the moment.
>> But that could change. I'd like to come up with a reliable
>> mechanism that would let us prevent these popups in both
>> tests and examples, just in case. Perhaps a good place for it
>> would be the <examples.h> header, although preferably without
>> relying on the coupling between the header and the example sources:
>>
>> https://issues.apache.org/jira/browse/STDCXX-425
>
> I can make the function i.e. init_example() in which all needed hooks
> are installed, but this function should be invoked from main() in all
> examples.
I was hoping to do it in a non-intrusive way. For instance, on UNIX
we could link with (or preload) a shared library that would in its
startup code run the function. Or we could use a command line option
to the preprocessor (such as gcc -include <file>) to include a header
containing the definition of such a function:
http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Preprocessor-Options.html#index-include-634
Does MSVC have something similar?
Martin
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Monday, July 09, 2007 7:44 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>
> >> We'll also need a solution for those executables (but we can worry
> >> about that once we're done enhancing the test driver).
> >
> > We can install the similar handlers in each example, but I don't
> > see any 2) of 3) popups in examples at the moment.
>
> But that could change. I'd like to come up with a reliable
> mechanism that would let us prevent these popups in both
> tests and examples, just in case. Perhaps a good place for it
> would be the <examples.h> header, although preferably without
> relying on the coupling between the header and the example sources:
>
> https://issues.apache.org/jira/browse/STDCXX-425
I can make the function i.e. init_example() in which all needed hooks
are installed, but this function should be invoked from main() in all
examples.
Farid.
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Tuesday, July 03, 2007 7:08 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Intel C++ build issues on Windows
>>
>>> There are 3 types of popup's:
>>> 1) Dr.Watson window, appear on access violation or unhandled
>>> exception;
>>> 2) CRT asserts ;
>>> 3) Parameter validattion handler popup's.
>>>
>>> The 1) prevented in exec utility (SetErrorMode()). The 2) and 3)
>>> might be prevented by installing report hook and invalid parameter
>>> handler:
>>>
>>>
>> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.h
>>> tm
>>> l
>> Gotcha! I see I still owe you a response to your feedback in
>> that thread. The solution in 2) and 3) will only take care of
>> these popups in tests and not in examples or config tests (or
>> locales?)
>
> Yes.
>
>> We'll also need a solution for those executables
>> (but we can worry about that once we're done enhancing the
>> test driver).
>
> We can install the similar handlers in each example, but I don't see
> any 2) of 3) popups in examples at the moment.
But that could change. I'd like to come up with a reliable mechanism
that would let us prevent these popups in both tests and examples,
just in case. Perhaps a good place for it would be the <examples.h>
header, although preferably without relying on the coupling between
the header and the example sources:
https://issues.apache.org/jira/browse/STDCXX-425
Martin
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, July 03, 2007 7:08 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>
> > There are 3 types of popup's:
> > 1) Dr.Watson window, appear on access violation or unhandled
> > exception;
> > 2) CRT asserts ;
> > 3) Parameter validattion handler popup's.
> >
> > The 1) prevented in exec utility (SetErrorMode()). The 2) and 3)
> > might be prevented by installing report hook and invalid parameter
> > handler:
> >
> >
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.h
> > tm
> > l
>
> Gotcha! I see I still owe you a response to your feedback in
> that thread. The solution in 2) and 3) will only take care of
> these popups in tests and not in examples or config tests (or
> locales?)
Yes.
> We'll also need a solution for those executables
> (but we can worry about that once we're done enhancing the
> test driver).
We can install the similar handlers in each example, but I don't see
any 2) of 3) popups in examples at the moment.
Farid.
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
>> Sent: Monday, July 02, 2007 9:09 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: RE: Intel C++ build issues on Windows
>>
>>> I see. I thought we cleaned them all up. Farid, are there any more
>>> tests or examples that you're aware of that could be causing this?
>>> I suppose it's always possible that a test will crash and pop up a
>>> window on the screen (what a pain!) We really need to 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
>
> I have sent unfinished message. Here the corrections:
>
> There are 3 types of popup's:
> 1) Dr.Watson window, appear on access violation or unhandled
> exception;
> 2) CRT asserts ;
> 3) Parameter validattion handler popup's.
>
> The 1) prevented in exec utility (SetErrorMode()). The 2) and 3)
> might be prevented by installing report hook and invalid parameter
> handler:
>
> http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.htm
> l
Gotcha! I see I still owe you a response to your feedback in that
thread. The solution in 2) and 3) will only take care of these
popups in tests and not in examples or config tests (or locales?)
We'll also need a solution for those executables (but we can worry
about that once we're done enhancing the test driver).
Martin
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> Sent: Monday, July 02, 2007 9:09 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: Intel C++ build issues on Windows
>
> > I see. I thought we cleaned them all up. Farid, are there any more
> > tests or examples that you're aware of that could be causing this?
> > I suppose it's always possible that a test will crash and pop up a
> > window on the screen (what a pain!) We really need to 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
I have sent unfinished message. Here the corrections:
There are 3 types of popup's:
1) Dr.Watson window, appear on access violation or unhandled
exception;
2) CRT asserts ;
3) Parameter validattion handler popup's.
The 1) prevented in exec utility (SetErrorMode()). The 2) and 3)
might be prevented by installing report hook and invalid parameter
handler:
http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.htm
l
Farid.
RE: Intel C++ build issues on Windows
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Friday, June 29, 2007 9:53 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Intel C++ build issues on Windows
>
> Andrew Black wrote:
> > Greetings Martin
> >
> > It appears that the build that started on 6/27 entered a hang state
> > due to an undismissed dialog. The utility used to
> automatically close
> > dialogs was failing for some reason, and the team
> responsible for the
> > automated build system has been working on resolving it.
>
> I see. I thought we cleaned them all up. Farid, are there any
> more tests or examples that you're aware of that could be
> causing this?
> I suppose it's always possible that a test will crash and pop
> up a window on the screen (what a pain!) We really need to
> 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
>
> >
> > The other two builds that started last night have completed, though
> > are reporting back in a ERROR state.
>
> So they are. The config header or log aren't available, even
> though it looks like they were successfully created. There
> might be useful information in there. Are they not getting
> saved in the database?
> And if not, is there a way to save them?
>
> Since Farid says he can't reproduce it in his environment
> there must be a difference between ours and his.
>
> Farid, what is the exact version of Intel C++ and MSVC that
> you're using on Windows? Our logs indicate we are at 9.1.028
> for icl and Visual Studio 2005. Andrew, do you know if we're
> have a service pack installed for Visual Studio and if so,
> 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
> (including patches or service packs) of theses things on
> Windows? If there is, would it be possible to enhance the
> Windows infrastructure to write all this information out
> somewhere? E.g., as the first step of the configuration
> process where we currently say (something like):
>
> Configuring for icc-9.1 - 12d Optimized Thread-safe Dll
>
> It would be useful to enhance this to give more detail, e.g.,
>
> 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.
Re: Intel C++ build issues on Windows
Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Greetings Martin
>
> It appears that the build that started on 6/27 entered a hang state due
> to an undismissed dialog. The utility used to automatically close
> dialogs was failing for some reason, and the team responsible for the
> automated build system has been working on resolving it.
I see. I thought we cleaned them all up. Farid, are there any more
tests or examples that you're aware of that could be causing this?
I suppose it's always possible that a test will crash and pop up
a window on the screen (what a pain!) We really need to come up
with a reliable way to prevent this.
>
> The other two builds that started last night have completed, though are
> reporting back in a ERROR state.
So they are. The config header or log aren't available, even though
it looks like they were successfully created. There might be useful
information in there. Are they not getting saved in the database?
And if not, is there a way to save them?
Since Farid says he can't reproduce it in his environment there
must be a difference between ours and his.
Farid, what is the exact version of Intel C++ and MSVC that you're
using on Windows? Our logs indicate we are at 9.1.028 for icl and
Visual Studio 2005. Andrew, do you know if we're have a service
pack installed for Visual Studio and if so, what version it is?
Ditto for the OS.
Farid, is there a way to determine the exact versions (including
patches or service packs) of theses things on Windows? If there
is, would it be possible to enhance the Windows infrastructure
to write all this information out somewhere? E.g., as the first
step of the configuration process where we currently say
(something like):
Configuring for icc-9.1 - 12d Optimized Thread-safe Dll
It would be useful to enhance this to give more detail, e.g.,
Configuring for icc-9.1.028 (Visual Studion 2005, Service
Pack X) - 12d Optimized Thread-safe Dll on Windows 2000,
Service Pack Y.
Martin
>
> --Andrew Black
>
> Martin Sebor wrote:
>> The Windows 2000 Intel C++ 9.1 builds have been in WAIT state
>> since 6/27. Andrew, in case you missed my note from last night,
>> can you please look and see what the problem is?
>>
>> The same builds on Windows 2003 all failed with the error below.
>> Farid, if you're not already investigating it can you please do
>> so?
>>
>> Thanks
>> Martin
>>
>> Compiling stdcxx library...
>>
>> D:\bman5\builds\33780929\source-buildspace\etc\config\windows\build.wsf(163,
>> 14) (null): Invalid pointer
>>
>> Summary log was generated in
>> file://D:/bman5/builds/33780929/source-buildspace/build/icc-9.1-11s.html
>> build complete
Re: Intel C++ build issues on Windows
Posted by Andrew Black <ab...@roguewave.com>.
Greetings Martin
It appears that the build that started on 6/27 entered a hang state due
to an undismissed dialog. The utility used to automatically close
dialogs was failing for some reason, and the team responsible for the
automated build system has been working on resolving it.
The other two builds that started last night have completed, though are
reporting back in a ERROR state.
--Andrew Black
Martin Sebor wrote:
> The Windows 2000 Intel C++ 9.1 builds have been in WAIT state
> since 6/27. Andrew, in case you missed my note from last night,
> can you please look and see what the problem is?
>
> The same builds on Windows 2003 all failed with the error below.
> Farid, if you're not already investigating it can you please do
> so?
>
> Thanks
> Martin
>
> Compiling stdcxx library...
>
> D:\bman5\builds\33780929\source-buildspace\etc\config\windows\build.wsf(163,
> 14) (null): Invalid pointer
>
> Summary log was generated in
> file://D:/bman5/builds/33780929/source-buildspace/build/icc-9.1-11s.html
> build complete