[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26484: feature request: add ICC support on Windows
From: |
Michael Haubenwallner |
Subject: |
bug#26484: feature request: add ICC support on Windows |
Date: |
Thu, 20 Apr 2017 13:07:23 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 |
On 04/18/2017 10:14 AM, address@hidden 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/