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

[Nikola Smiljanic]

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?
>
> 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/20140116/efd174e4/attachment.html>