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

Ruben Van Boxem vanboxem.ruben at gmail.com
Sun Jan 19 06:38:12 PST 2014

2014/1/16 Nikola Smiljanic <popizdeh at gmail.com>

> 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?
> On Thu, Jan 16, 2014 at 9:16 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com
> > wrote:
>> 2014/1/14 Reid Kleckner <rnk at google.com>
>>> On Sun, Jan 12, 2014 at 3:20 AM, Ruben Van Boxem <
>>> vanboxem.ruben at gmail.com> wrote:
>>>> 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 :-)
>>>> 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.  :)  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:

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.



>> 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.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140119/a878c8eb/attachment.html>

More information about the cfe-dev mailing list