Clang and (cross-)compilation to [i686, x86_64]-w64-mingw32

Hi,

I’m planning to take a much-needed look at MinGW(-w64) compatibility in the Clang driver. What I’m hoping to accomplish is the following:

  1. allow ‘clang -target [i686,x86_64]-w64-mingw32’ to:
    1a) search /usr/[i686,x86_64]-w64-mingw32/[include,lib] and certain subdirectories for C(++) headers and libraries,

1b) use [i686,x86_64]-w64-mingw32-[as,ld,…] instead of what is currently (as of Clang 3.3 in my Arch Linux installation, will soon test a top of trunk build) [as,ld,…]

1c) set the necessary libraries to link in various situations.

  1. Build a toolchain:
    2a) that uses GNU binutils, Clang, and GNU libgcc/libstdc++ and make it work.

2b) that uses GNU binutils, Clang, LLVM compiler-rt, and GNU libstdc++ and make it work.

For this, I’d like to introduce a new Toolchain subclass, MinGWToolchain, which takes care of the --mingw32 triplets.

I’m unsure of several things:

  1. where is the target triple “converted” into a Toolchain instance?

  2. how can I pass triplet-specific include dirs at configure/cmake time? This would not really be necessary, but actually really is if Clang is to be used as an “ultra-cross”-compiler targetting every triplet under the sun from one binary (which is an awesome idea).

I have read the sparse Driver documentation, and unfortunately not found an answer to the above issues. I would appreciate any substantial help anyone can give me in these departments. I’d like to do this right so the changes can stay (unlike my previous InitHeaderSearch hacks)

Thanks!

Ruben

PS: I’m not subscribed to cfe-dev, please CC me directly.

Hi,

I'm planning to take a much-needed look at MinGW(-w64) compatibility in
the Clang driver. What I'm hoping to accomplish is the following:
1. allow 'clang -target [i686,x86_64]-w64-mingw32' to:
1a) search /usr/[i686,x86_64]-w64-mingw32/[include,lib] and certain
subdirectories for C(++) headers and libraries,
1b) use [i686,x86_64]-w64-mingw32-[as,ld,...] instead of what is currently
(as of Clang 3.3 in my Arch Linux installation, will soon test a top of
trunk build) [as,ld,...]
1c) set the necessary libraries to link in various situations.
2) Build a toolchain:
2a) that uses GNU binutils, Clang, and GNU libgcc/libstdc++ and make it
work.
2b) that uses GNU binutils, Clang, LLVM compiler-rt, and GNU libstdc++ and
make it work.

Sounds good!

For this, I'd like to introduce a new Toolchain subclass, MinGWToolchain,
which takes care of the *-*-mingw32 triplets.

I'm unsure of several things:
1) where is the target triple "converted" into a Toolchain instance?

Driver::getToolChain() in Driver.cpp

2) how can I pass triplet-specific include dirs at configure/cmake time?
This would not really be necessary, but actually really is if Clang is to
be used as an "ultra-cross"-compiler targetting every triplet under the sun
from one binary (which is an awesome idea).

I'm not sure exactly what the question is.

I have read the sparse Driver documentation, and unfortunately not found
an answer to the above issues. I would appreciate any substantial help
anyone can give me in these departments. I'd like to do this right so the
changes can stay (unlike my previous InitHeaderSearch hacks)

We have driver documentation? I wasn't aware of it. :slight_smile: I'd look at
clang/test/Driver for some of the existing header / library search tests.

Hi,

I'm planning to take a much-needed look at MinGW(-w64) compatibility in
the Clang driver. What I'm hoping to accomplish is the following:
1. allow 'clang -target [i686,x86_64]-w64-mingw32' to:
1a) search /usr/[i686,x86_64]-w64-mingw32/[include,lib] and certain
subdirectories for C(++) headers and libraries,
1b) use [i686,x86_64]-w64-mingw32-[as,ld,...] instead of what is
currently (as of Clang 3.3 in my Arch Linux installation, will soon test a
top of trunk build) [as,ld,...]
1c) set the necessary libraries to link in various situations.
2) Build a toolchain:
2a) that uses GNU binutils, Clang, and GNU libgcc/libstdc++ and make it
work.
2b) that uses GNU binutils, Clang, LLVM compiler-rt, and GNU libstdc++
and make it work.

Sounds good!

For this, I'd like to introduce a new Toolchain subclass, MinGWToolchain,
which takes care of the *-*-mingw32 triplets.

I'm unsure of several things:
1) where is the target triple "converted" into a Toolchain instance?

Driver::getToolChain() in Driver.cpp

2) how can I pass triplet-specific include dirs at configure/cmake
time? This would not really be necessary, but actually really is if Clang
is to be used as an "ultra-cross"-compiler targetting every triplet under
the sun from one binary (which is an awesome idea).

I'm not sure exactly what the question is.

I was talking about the --with-c-include-dirs and associated configure
options. But I now believe my MinGWToolChain and related work will include
these settings hardcoded in the driver, which is much better. So forget
this question :slight_smile:

I have read the sparse Driver documentation, and unfortunately not found
an answer to the above issues. I would appreciate any substantial help
anyone can give me in these departments. I'd like to do this right so the
changes can stay (unlike my previous InitHeaderSearch hacks)

We have driver documentation? I wasn't aware of it. :slight_smile: I'd look at
clang/test/Driver for some of the existing header / library search tests.

OK, thanks. I'll be sure to take a look there.

Attached is a *preliminary* patch adding MinGW-w64 driver support. This
includes:
- C(++) system include directories
- C(++) system libraries
- basic "Hello World" C and C++ test compiles and links on Arch Linux with
the mingw-w64-gcc toolchain packages installed. Clang now calls the cross
binutils directly instead of linking with cross gcc.

This patch is missing:
- more than basic testing (including a Windows native Clang, which will
take some manual installation steps)
- dll import lib options,
- MinGW(.org) search directories. I'll get to this once I solve the next
point;
- Cross GCC version detection: I know the Generic_GCC ToolChain has
machinery to do this, but it also adds the /usr/include and
/usr/local/include directories, and probably some native library
directories which I really really don't want. Is there an easy way to get
at the cross GCC version at the ToolChain level?

Once I get the GCC version (which is hardcoded in attached patch), I'll fix
up the rest and this should be ready in no time!

Another question for later: how do I build the libgcc replacing part of
compiler-rt for a specific target? Is there CMake build machinery to build
a number of target libraries or do I need to build them separately and
manually (not really a problem, just need to know how)?

Cheers!

Ruben

PS: I'm not subscribed to cfe-dev, please CC me directly.

mingw-w64-driver.patch.txt (17.2 KB)

Hi Ruben, I’d just like to point you to test/Driver/linux-header-search.cpp for some testing ideas. I could also give this a try on windows if you’re only testing on linux?

Hi Ruben, I'd just like to point you to
test/Driver/linux-header-search.cpp for some testing ideas. I could also
give this a try on windows if you're only testing on linux?

Hi,

I'm planning to take a much-needed look at MinGW(-w64) compatibility in
the Clang driver. What I'm hoping to accomplish is the following:
1. allow 'clang -target [i686,x86_64]-w64-mingw32' to:
1a) search /usr/[i686,x86_64]-w64-mingw32/[include,lib] and certain
subdirectories for C(++) headers and libraries,
1b) use [i686,x86_64]-w64-mingw32-[as,ld,...] instead of what is
currently (as of Clang 3.3 in my Arch Linux installation, will soon test a
top of trunk build) [as,ld,...]
1c) set the necessary libraries to link in various situations.
2) Build a toolchain:
2a) that uses GNU binutils, Clang, and GNU libgcc/libstdc++ and make it
work.
2b) that uses GNU binutils, Clang, LLVM compiler-rt, and GNU libstdc++
and make it work.

Sounds good!

For this, I'd like to introduce a new Toolchain subclass,
MinGWToolchain, which takes care of the *-*-mingw32 triplets.

I'm unsure of several things:
1) where is the target triple "converted" into a Toolchain instance?

Driver::getToolChain() in Driver.cpp

2) how can I pass triplet-specific include dirs at configure/cmake
time? This would not really be necessary, but actually really is if Clang
is to be used as an "ultra-cross"-compiler targetting every triplet under
the sun from one binary (which is an awesome idea).

I'm not sure exactly what the question is.

I was talking about the --with-c-include-dirs and associated configure
options. But I now believe my MinGWToolChain and related work will include
these settings hardcoded in the driver, which is much better. So forget
this question :slight_smile:

I have read the sparse Driver documentation, and unfortunately not
found an answer to the above issues. I would appreciate any substantial
help anyone can give me in these departments. I'd like to do this right so
the changes can stay (unlike my previous InitHeaderSearch hacks)

We have driver documentation? I wasn't aware of it. :slight_smile: I'd look at
clang/test/Driver for some of the existing header / library search tests.

OK, thanks. I'll be sure to take a look there.

Attached is a *preliminary* patch adding MinGW-w64 driver support. This
includes:
- C(++) system include directories
- C(++) system libraries
- basic "Hello World" C and C++ test compiles and links on Arch Linux
with the mingw-w64-gcc toolchain packages installed. Clang now calls the
cross binutils directly instead of linking with cross gcc.

This patch is missing:
- more than basic testing (including a Windows native Clang, which will
take some manual installation steps)
- dll import lib options,
- MinGW(.org) search directories. I'll get to this once I solve the next
point;
- Cross GCC version detection: I know the Generic_GCC ToolChain has
machinery to do this, but it also adds the /usr/include and
/usr/local/include directories, and probably some native library
directories which I really really don't want. Is there an easy way to get
at the cross GCC version at the ToolChain level?

All the above, except MinGW.org search directories has been done. I opened
up a bug report for this so the discussion on it can be localized there:
http://llvm.org/bugs/show_bug.cgi?id=18546

Three things currently missing:
- proper fix for DllMainCRTStartup missing entry point
- MinGW.org search paths
- unit tests

I'd appreciate help in the last department, and if someone could test and
provide any insight for the first one, I'd appreciate it. I'll get to the
second one when I find the time.

Cheers!

Ruben