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 <[email protected]>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:* [email protected] [mailto:[email protected]] *On > Behalf Of *Justin Holewinski > *Sent:* Thursday, May 24, 2012 1:49 PM > *To:* Brad King > *Cc:* [email protected] > *Subject:* Re: [CMake] Clang + MinGW Linking Issue**** > > ** ** > > On Thu, May 24, 2012 at 10:08 AM, Brad King <[email protected]> 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
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
