[CMake] Clang + MinGW Linking Issue

Justin Holewinski justin.holewinski at gmail.com
Thu May 24 18:27:32 EDT 2012


Were you passing custom command-line arguments in the project?  Clang only
accepts a very limited set of CL-style arguments (AFAIK):

>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe

>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
-Zm
clang: error: unsupported use of internal gcc -Z option '-Zm'

>c:\projects\llvm-dev\build-3.1\bin\clang clang-test.c -out:clang-test.exe
-MT
clang: error: argument to '-MT' is missing (expected 1 value)

This is with a Clang built with the compilers from the Windows SDK 7.1.

On Thu, May 24, 2012 at 2:12 PM, Keith Gardner <kgardner at zebraimaging.com>wrote:

> I have built clang (llvm) on windows with Visual Studio 2010 and used the
> built binaries as the compiler inside of a Visual Studio project.  This was
> with clang 3.0 and llvm 2.9.1.****
>
> ** **
>
> *From:* cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] *On
> Behalf Of *Justin Holewinski
> *Sent:* Thursday, May 24, 2012 1:49 PM
> *To:* Brad King
> *Cc:* cmake at cmake.org
> *Subject:* Re: [CMake] Clang + MinGW Linking Issue****
>
> ** **
>
> On Thu, May 24, 2012 at 10:08 AM, Brad King <brad.king at kitware.com> wrote:
> ****
>
> On 05/24/2012 12:22 PM, Justin Holewinski wrote:
> > I narrowed the problem down to Clang not having
> Platform/Windows-Clang-{C,CXX}.cmake files.****
>
> There is an issue tracker entry for this:
>
>  http://www.cmake.org/Bug/view.php?id=13035
>
> but it is in the backlog waiting for more feedback and a volunteer.
> The main problem is distinguishing the GNU-compatible and MS-compatible
> builds of Clang.****
>
> ** **
>
> Oops, missed that issue.  Sorry about that!****
>
>  ****
>
>
> >  If I add the following two files then everything starts to work as
> expected:
> >
> > Platform/Windows-Clang-C.cmake:
> >
> > if(MINGW)
> >   include(Platform/Windows-GNU)
> >   __windows_compiler_gnu(C)
> > else()
> >   # Chain to generic Windows configuration
> >   include(Platform/Windows)
> > endif()
> >
> > Platform/Windows-Clang-CXX.cmake:
> >
> > if(MINGW)
> >   include(Platform/Windows-GNU)
> >   __windows_compiler_gnu(C)
> > else()
> >   # Chain to generic Windows configuration
> >   include(Platform/Windows)
> > endif()
> >
> > This way, using Clang with MinGW will force GNU-style platform
> > options instead of VS-style Windows options.
> > Is this more or less the "right way" to fix this in CMake?****
>
> Interesting approach.  That may be better than separating the
> compiler id as mentioned in the above-linked issue.  The "MINGW"
> value is set based on CMAKE_C_PLATFORM_ID which is computed in
> the same way and at the same time as CMAKE_C_COMPILER_ID.  Try:
>
>  $ cat Platform/Windows-Clang-C.cmake
>  if("${CMAKE_C_PLATFORM_ID}" MATCHES "MinGW")
>   include(Platform/Windows-GNU-C)
>  else()
>   include(Platform/Windows-cl)
>  endif()
>
>  $ cat Platform/Windows-Clang-CXX.cmake
>  if("${CMAKE_CXX_PLATFORM_ID}" MATCHES "MinGW")
>   include(Platform/Windows-GNU-CXX)
>  else()
>   include(Platform/Windows-cl)
>  endif()
>
> Do you have both the MS-style and GNU-style Clang available
> to test?****
>
> ** **
>
> This works for the MinGW build.  I really can't say if this fixes the
> library naming issue for the MS-style Clang.  Clang does not have a
> VC-compatible driver (that I know of) so does not accept VC-style arguments
> like "/O2", which causes CMake to fail early on in the configure process
> when using the NMake generator.  Clang with MinGW is the only really
> supported configuration at this point.****
>
>  ****
>
>
> Thanks,
> -Brad****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Thanks,****
>
> ** **
>
> Justin Holewinski****
>
> ** **
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120524/d25f663e/attachment.htm>


More information about the CMake mailing list