GNU bug report logs - #26484
feature request: add ICC support on Windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26484 in the body.
You can then email your comments to 26484 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: sav_ix <at> ukr.net
To: bug-libtool <at> gnu.org
Subject: feature request: add ICC support on Windows
Date: Thu, 13 Apr 2017 18:01:59 +0300

[Message part 1 (text/plain, inline)]

Hello, 

Currently ICC, like MSVC, offer free versions for Open Source development on Windows (https://software.intel.com/en-us/qualify-for-free-software/opensourcecontributor ). Thus a lot of Open Source tools, which use autotools build system (GMP/MPIR, MPFR, libiconv, etc.), could be built using free Intel Compiler, which offer a better performance (https://software.intel.com/en-us/c-compilers/ipsxe ). 

Currently autotools doesn't provide ICC support "out of the box". But, fortunately , it provide such support for MSVC. And since ICC on Win dows tries to emulate MSVC (by using same compiler keys, MSVC linker, etc.), it's pretty easy to adopt MSVC toolchain from 'configure' script for this purpose. 

E.g., in order to add ICC support for libiconv-1.15 ( https://ftp.gnu.org/gnu/libiconv/libiconv-1.15.tar.gz ) build system, a very simple patch required (see attachment). 

But since content of 'configure' script relate to file 'libtool.m4', it would be more convenient, if libtool provide ICC support "out of the box" . 

Is it possible to add ICC support to the future libtool releases ? 


Alexander 

[Message part 2 (text/html, inline)]

[libiconv_i.diff (application/octet-stream, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: bug-libtool <at> gnu.org
Subject: Re: bug#26484: feature request: add ICC support on Windows
Date: Fri, 14 Apr 2017 08:48:35 -0400

On 4/13/2017 11:01 AM, sav_ix <at> ukr.net wrote:
> Hello,
> 
> Currently ICC, like MSVC, offer free versions for Open Source
> development on Windows
> (https://software.intel.com/en-us/qualify-for-free-software/opensourcecontributor
> ). Thus a lot of Open Source tools, which use autotools build system
> (GMP/MPIR, MPFR, libiconv, etc.), could be built using free Intel
> Compiler, which offer a better performance
> (https://software.intel.com/en-us/c-compilers/ipsxe ).
> 
> Currently autotools doesn't provide ICC support "out of the box". But,
> fortunately , it provide such support for MSVC. And since ICC on Windows
> tries to emulate MSVC (by using same compiler keys, MSVC linker, etc.),
> it's pretty easy to adopt MSVC toolchain from 'configure' script for
> this purpose.
> 
> E.g., in order to add ICC support for libiconv-1.15
> (https://ftp.gnu.org/gnu/libiconv/libiconv-1.15.tar.gz ) build system, a
> very simple patch required (see attachment).
> 
> But since content of 'configure' script relate to file 'libtool.m4', it
> would be more convenient, if libtool provide ICC support "out of the box".
> 
> Is it possible to add ICC support to the future libtool releases?

Instead of obliterating cl by replacing it with icl why don't you patch
it so that it could be either one?

-- 
Earnie

Message #11 received at 26484 <at> debbugs.gnu.org (full text, mbox):

From: sav_ix <at> ukr.net
To: 26484 <at> debbugs.gnu.org
Subject: bug#26484: feature request: add ICC support on Windows
Date: Tue, 18 Apr 2017 11:14:18 +0300

[Message part 1 (text/plain, inline)]

The essential ICC feature, that it tries to be GCC on *unix and MSVC on Windows. E.g. on Windows it has almost the same compiler keys, use MSVC Linker and Librarian, Windows SDK headers, etc. For this purpose ICC uses ' VS20xx x64 Native Tools Command Prompt ' to prepare environment. And thus both ICC (icl.exe) and MSVC (cl.exe) compilers are available in PATH variable during ICC run. 

I didn't find any other way to make libtool use ICC, except to adopt MSVC toolchain for ICC . But I have no idea how to make them both to use the same toolchain. Perhaps, the solution could be replace all entries of 'cl.exe' with ${CC} and ${CXX} and set its default values to 'cl.exe'. But still an opened question how to make ICC use '*.cl*)' toolchain. Would be appreciated for any hints. 

And even if it can be solved, it's still not much could be done without libtool Developers. I s there a chance, that someone will be engaged in this feature request? 


Alexander 

[Message part 2 (text/html, inline)]

Message #14 received at 26484 <at> debbugs.gnu.org (full text, mbox):

From: Michael Haubenwallner <michael.haubenwallner <at> ssi-schaefer.com>
To: sav_ix <at> ukr.net, 26484 <at> debbugs.gnu.org
Subject: Re: bug#26484: feature request: add ICC support on Windows
Date: Thu, 20 Apr 2017 13:07:23 +0200

On 04/18/2017 10:14 AM, sav_ix <at> ukr.net wrote:
> The essential ICC feature, that it tries to be GCC on *unix and MSVC on Windows.
> E.g. on Windows it has almost the same compiler keys, use MSVC Linker and Librarian, Windows SDK headers, etc.
> For this purpose ICC uses 'VS20xx x64 Native Tools Command Prompt' to prepare environment.
> And thus both ICC (icl.exe) and MSVC (cl.exe) compilers are available in PATH variable during ICC run.

I'm on a similar issue: There's a wrapper around the MSVC toolchain,
which was originally running on Interix and now runs on Cygwin too,
that does provide a GCC-like commandline interface while running
cl.exe/link.exe/etc. behind the scenes, without the need to set up
any additional MSVC-based environment variables for the POSIX shell.
Beyond that, it does add support for embedded runpath, LD_PRELOAD
and LD_LIBRARY_PATH by statically linking some kind of runtime loader
to each binary (dll or exe): https://github.com/haubi/parity

Independend of parity: In Interix /usr/bin/, cc and c89 actually are
Korn shell scripts, which do provide the basic *nix-like commandline
interface, also calling cl.exe & Co behind the scenes, but without
extended features like parity.

> I didn't find any other way to make libtool use ICC, except to adopt MSVC toolchain for ICC.
> But I have no idea how to make them both to use the same toolchain.
> Perhaps, the solution could be replace all entries of 'cl.exe' with ${CC} and ${CXX} and set its default values to 'cl.exe'.
> But still an opened question how to make ICC use '*.cl*)' toolchain.
> Would be appreciated for any hints.

So rather than testing for the compiler executable file name, I'd prefer
to test for compiler features and behaviour instead.

> And even if it can be solved, it's still not much could be done without libtool Developers.
> Is there a chance, that someone will be engaged in this feature request?

Although not a libtool developer, I'm about to do the development and
file patches afterwards, but won't promise any due date.

But for ICC, I fail to find the Windows version for Open Source Contributors:
Which one do you refer to here?

/haubi/

Message #17 received at 26484 <at> debbugs.gnu.org (full text, mbox):

From: sav_ix <at> ukr.net
To: Michael Haubenwallner <michael.haubenwallner <at> ssi-schaefer.com>
Cc: 26484 <at> debbugs.gnu.org
Subject: bug#26484: feature request: add ICC support on Windows
Date: Thu, 20 Apr 2017 18:10:37 +0300

[Message part 1 (text/plain, inline)]

  

--- Исходное сообщение --- 
От кого: "Michael Haubenwallner" <michael.haubenwallner <at> ssi-schaefer.com> 
Дата: 20 апреля 2017, 14:07:30 


I'm on a similar issue... 
BTW, did you seen ICU4C (http://site.icu-project.org/download) build system? It also "provide a GCC-like commandline interface while running cl.exe/link.exe/etc. behind the scenes ". It's somewhat similar to autotools-generated ones, but instead of using 'libtool' it provide compiler toolchains as a separate files. Such a modular structure makes it much easier to add support of new compilers. Could be that you find some useful ideas there. 

So rather than testing for the compiler executable file name, I'd prefer
to test for compiler features and behaviour instead. 
Not the simplest approach and, perhaps, hard to maintain. Many build systems, e.g. Boost ( bjam ), MESA (SCons), OpenSSL, Qt (qmake), etc., just imply, that the User knows what compiler he has and what toolchain to select. And if User made a mistake, he would get an error during build. 

Although not a libtool developer, I'm about to do the development and
file patches afterwards, but won't promise any due date. 
With interest would acquaint with the results . ICC offers some advantages, compared to other compilers (https://software.intel.com/en-us/c-compilers/ipsxe ), thus it d efinitely deserves support from modern build systems . 

But for ICC, I fail to find the Windows version for Open Source Contributors:
Which one do you refer to here? 
There are details regarding this question. Officially Intel do not claim, that they provide free ICC version on Windows for Open Source Development. Currently they offer free ICC on Windows license for Educators and Students (https://software.intel.com/en-us/qualify-for-free-software ). But it is for the time being and could change in future (https://software.intel.com/en-us/forums/intel-c-compiler/topic/639321). 

In addition they offer a free 30-days Trial (https://software.intel.com/en-us/intel-parallel-studio-xe ). But in case you're interested to get a free ICC on Windows license for Open Source Development, I can share contact of Intel representative, who could help with this. 


Alexander 

[Message part 2 (text/html, inline)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: sav_ix <at> ukr.net
To: bug-libtool <at> gnu.org
Cc: peda <at> lysator.liu.se, jonathan.l.peyton <at> intel.com
Subject: bug#26484: feature request: add ICC support on Windows
Date: Sun, 21 Jan 2018 19:20:43 +0200

[Message part 1 (text/plain, inline)]

Hello,

After Windows ICC support was added to 'compile' script, similar could be done to 'libtool.m4'.

Related patch added in attachment. It was tested for GMP builds using Windows ICC with <shared|static> layouts, and all builds tasks finished successfully. Additionally ensured, that it doesn't break builds using MSVC.


CC: Peter Rosin, as Author of commit (http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=1ac3ced59db72099c6049e05b3643042fd5a9ea4),
CC: Jonathan L Peyton, as Author of commit (http://git.savannah.gnu.org/cgit/automake.git/commit/?id=c40e27e1c2a60f58e72e65d73d808f782d55494a),

in case they'll be interested to make review aor join this discussion.


Best,

Alexander

[Message part 2 (text/html, inline)]

[libtool_icc.diff (application/octet-stream, attachment)]

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: sav_ix <at> ukr.net, jonathan.l.peyton <at> intel.com, peda <at> lysator.liu.se,
 26484 <at> debbugs.gnu.org
Subject: Re: bug#26484: feature request: add ICC support on Windows
Date: Thu, 12 Jul 2018 11:54:34 +0200

close 26484 2.4.6.41-99bd0
thanks

On Sunday, January 21, 2018 6:20:43 PM CEST sav_ix <at> ukr.net wrote:
> After Windows ICC support was added to 'compile' script, similar could be done
> to 'libtool.m4'.
> 
> Related patch added in attachment. It was tested for GMP builds using Windows
> ICC with <shared|static> layouts, and all builds tasks finished successfully.
> Additionally ensured, that it doesn't break builds using MSVC.

Thanks, applied here:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?h=HEAD&id=99bd0948e20ca796c0d38dee606965b86ce0832a

Any review is welcome, especially if you are able to test the patch properly.

Pavel

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.