Beman Dawes | 11 Nov 22:20
Favicon

[intel] Intel 11.0 on Windows breaking change

Intel 11.0 for Windows shipped November 5th. There seems to be a 
breaking change; iclvars.bat now expects an argument, which must be one 
of ia32, ia32_intel64, intel64, ia32_ia64, or ia64.

Builds are failing; command lines being issued are missing the command 
at the beginning of the command line.

Who looks after the intel tool files?

Thanks,

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Vladimir Prus | 12 Nov 06:48
Favicon

Re: [intel] Intel 11.0 on Windows breaking change

Beman Dawes wrote:

> Intel 11.0 for Windows shipped November 5th. There seems to be a
> breaking change; iclvars.bat now expects an argument, which must be one
> of ia32, ia32_intel64, intel64, ia32_ia64, or ia64.

Did you already submit a bug report to Intel about this?

> Builds are failing; command lines being issued are missing the command
> at the beginning of the command line.
> 
> Who looks after the intel tool files?

Nobody in particular, but that's not important question. Who gets to *test*
whatever changes I might make? Where's documentation for those options? 

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

John Maddock | 12 Nov 13:59

Re: [intel] Intel 11.0 on Windows breaking change

Vladimir Prus wrote:
>> Beman Dawes wrote:
>>
>>> Intel 11.0 for Windows shipped November 5th. There seems to be a
>>> breaking change; iclvars.bat now expects an argument, which must be
>>> one of ia32, ia32_intel64, intel64, ia32_ia64, or ia64.
>>
>> Did you already submit a bug report to Intel about this?

I don't believe this is an Intel bug as such - those batch file are 
undocumented details - the documentation always refers you to start menu 
items thats load up a working command prompt with the relevent batch file 
already called.

For the record though, there is now a choice, the directory structure looks 
like:

Intel/Compiler/11.0/$(patch-version)/cpp/bin/
  iclvars.bat
  ia32/
    iclvars_ia32.bat

The iclvars.bat file requires a command line argument as noted previously, 
while the iclvars_$(arch).bat does not (the former just forwards to the 
latter).  So... the problem can be solved either:

* By allowing the Intel configuration to specify the batch file and 
arguments to run seperately from the icl command to use.
* By allowing the Intel configuration to specify the batch file to invoke, 
rather than the icl compiler to invoke.
(Continue reading)

Vladimir Prus | 22 Nov 10:09

Re: [intel] Intel 11.0 on Windows breaking change

On Wednesday 12 November 2008 15:59:32 John Maddock wrote:
> Vladimir Prus wrote:
> >> Beman Dawes wrote:
> >>
> >>> Intel 11.0 for Windows shipped November 5th. There seems to be a
> >>> breaking change; iclvars.bat now expects an argument, which must be
> >>> one of ia32, ia32_intel64, intel64, ia32_ia64, or ia64.
> >>
> >> Did you already submit a bug report to Intel about this?
> 
> I don't believe this is an Intel bug as such - those batch file are 
> undocumented details - the documentation always refers you to start menu 
> items thats load up a working command prompt with the relevent batch file 
> already called.
> 
> For the record though, there is now a choice, the directory structure looks 
> like:
> 
> Intel/Compiler/11.0/$(patch-version)/cpp/bin/
>   iclvars.bat
>   ia32/
>     iclvars_ia32.bat
> 
> The iclvars.bat file requires a command line argument as noted previously, 
> while the iclvars_$(arch).bat does not (the former just forwards to the 
> latter).  So... the problem can be solved either:
> 
> * By allowing the Intel configuration to specify the batch file and 
> arguments to run seperately from the icl command to use.
> * By allowing the Intel configuration to specify the batch file to invoke, 
(Continue reading)

John Maddock | 22 Nov 10:43

Re: [intel] Intel 11.0 on Windows breaking change

Vladimir Prus wrote:
>> I think the right solution is the same as for msvc -- use
>> information about
>> host, and 'architecture' feature to pass the right value. I'll try
>> to make
>> this happen.
>>
>> Can you tell how this all is related to msvc? Is intel compiler now
>> completely standalone product, or it requires msvc compiler as
>> backend? If so, which
>> msvc compiler is used, and do we need to do anything about that when
>> implementing this new behaviour?

It requires msvc for the linker and for std lib headers and binaries.

As for which msvc compiler that's a thorny issue: it's set by the user when 
they install Intel C++.  I think as far as bjam is concerned it can be 
treated "as if" it's a standalone compiler.

HTH, John. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build


Gmane