Re: [CMake] Clang + MinGW Linking Issue
Hi Again,
I narrowed the problem down to Clang not having
Platform/Windows-Clang-{C,CXX}.cmake files. 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?
On Wed, May 23, 2012 at 3:22 PM, Justin Holewinski
justin.holewin...@gmail.com wrote:
Hi All,
I've been trying out CMake for building C++ applications on Windows with
Clang, using the MinGW headers/libraries. This works fine, except if I
need to pull in non-default system libraries that are included with MinGW,
such as libpsapi.a (psapi.lib for VS). For example, if I have the
following CMakeLists.txt file:
project(pstest1)
add_executable(pstest1 pstest1.cpp)
target_link_libraries(pstest1 psapi)
This fails with a linker error:
Linking CXX executable pstest1.exe
c:\projects\cmake-2.8.8-win32-x86\bin\cmake.exe -E cmake_link_script
CMakeFiles\pstest1.dir\link.txt --verbose=1
C:\projects\clang+llvm-3.1-i386-mingw32-EXPERIMENTAL\bin\clang++.exe
CMakeFiles/pstest1.dir/pstest1.obj -o pst
est1.exe *-lpsapi.lib*
*c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe:
cannot find -lpsapi.lib*
collect2: ld returned 1 exit status
clang++: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)
mingw32-make[2]: *** [pstest1.exe] Error 1
mingw32-make[2]: Leaving directory `C:/projects/mingw-tests/pstest1/build'
mingw32-make[1]: *** [CMakeFiles/pstest1.dir/all] Error 2
mingw32-make[1]: Leaving directory `C:/projects/mingw-tests/pstest1/build'
mingw32-make: *** [all] Error 2
CMake seems to be using MSVC library naming conventions for Clang in MinGW
mode, but also using the GCC-style -l flags for specifying libraries. If I
replace
target_link_libraries(pstest1 psapi)
with
target_link_libraries(pstest1 c:/MinGW/lib/libpsapi.a)
then everything works as expected (I got -lpsapi on the link line).
Interestingly, everything also works correctly if I use the default
mingw32-gcc.exe compiler instead of clang.exe. So this seems to be a CMake
issue where it detects Clang but does not know how to properly pass
GCC-style linker flags to Clang.
Any ideas?
--
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
Re: [CMake] Clang + MinGW Linking Issue
On Thu, May 24, 2012 at 10:08 AM, Brad King brad.k...@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
--
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
Re: [CMake] Clang + MinGW Linking Issue
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 kgard...@zebraimaging.comwrote:
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-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
Behalf Of *Justin Holewinski
*Sent:* Thursday, May 24, 2012 1:49 PM
*To:* Brad King
*Cc:* cmake@cmake.org
*Subject:* Re: [CMake] Clang + MinGW Linking Issue
** **
On Thu, May 24, 2012 at 10:08 AM, Brad King brad.k...@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
--
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
[CMake] Clang + MinGW Linking Issue
Hi All, I've been trying out CMake for building C++ applications on Windows with Clang, using the MinGW headers/libraries. This works fine, except if I need to pull in non-default system libraries that are included with MinGW, such as libpsapi.a (psapi.lib for VS). For example, if I have the following CMakeLists.txt file: project(pstest1) add_executable(pstest1 pstest1.cpp) target_link_libraries(pstest1 psapi) This fails with a linker error: Linking CXX executable pstest1.exe c:\projects\cmake-2.8.8-win32-x86\bin\cmake.exe -E cmake_link_script CMakeFiles\pstest1.dir\link.txt --verbose=1 C:\projects\clang+llvm-3.1-i386-mingw32-EXPERIMENTAL\bin\clang++.exe CMakeFiles/pstest1.dir/pstest1.obj -o pst est1.exe *-lpsapi.lib* *c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lpsapi.lib* collect2: ld returned 1 exit status clang++: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) mingw32-make[2]: *** [pstest1.exe] Error 1 mingw32-make[2]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make[1]: *** [CMakeFiles/pstest1.dir/all] Error 2 mingw32-make[1]: Leaving directory `C:/projects/mingw-tests/pstest1/build' mingw32-make: *** [all] Error 2 CMake seems to be using MSVC library naming conventions for Clang in MinGW mode, but also using the GCC-style -l flags for specifying libraries. If I replace target_link_libraries(pstest1 psapi) with target_link_libraries(pstest1 c:/MinGW/lib/libpsapi.a) then everything works as expected (I got -lpsapi on the link line). Interestingly, everything also works correctly if I use the default mingw32-gcc.exe compiler instead of clang.exe. So this seems to be a CMake issue where it detects Clang but does not know how to properly pass GCC-style linker flags to Clang. Any ideas? -- 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
Re: [CMake] Cross-compiling, CMAKE_C_FLAGS, and configure-time compiler tests
On Tue, Dec 14, 2010 at 4:45 AM, Johan Björk p...@spotify.com wrote:
Hi Justin,
I'm very unsure if this is the correct solution, but it worked for me. I
haven't been able to find any good documentation stating how the CMakeCache
interacts with other parts of CMake.
My assumption is that since CMAKE_C{XX}_FLAGS is supposed to allow the user
to set optional compilation flags, it prefers the value in the cache versus
the one from the toolchain file.
From one of my toolchain files, reproduce as necessary for CMAKE_C_FLAGS:
SET(CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS} -fno-rtti CACHE STRING FORCE)
I'll have to give that a try. For now, I'm getting around the problem by
setting the flags within the parent CMakeLists.txt script after loading the
toolchain file.
I'm really not sure what the best practice is for this situation. The
compiler will work and can be tested without the -arch flags, but the
flags are necessary to build for the *right* architecture. Most
cross-compilers will only produce binaries for the target system, so the
point is moot. The iOS compilers, however, will generate code for Intel and
ARM so I'm not sure if testing the i386 back-end when I'm targeting ARM is
the right way or not.
Cheers
/Johan
On Mon, Dec 13, 2010 at 4:49 PM, Justin Holewinski
justin.holewin...@gmail.com wrote:
I am experiencing a cross-compiling issue that I believe is related to how
toolchain files interact with the configure-time compiler checks. For
reference, I am targeting the iOS 4.2 SDK. I have a toolchain file that
sets CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, CMAKE_C_LINK_FLAGS, and
CMAKE_CXX_LINK_FLAGS with appropriate flags for the iOS platform, in
particular -arch armv6 -arch armv7. The toolchain file also sets the
proper C and C++ compilers.
When CMake is executed and the C compiler is tested, the
toolchain-specified compiler arguments are passed to the link line, but
*not* the compile line (according to the error output). Since the compile
line does not contain the -arch arguments, the generated object file is
for i386. However, since the link line contains these flags, the linker
tries to link ARM code and fails.
Are there any additional variables I should be setting in addition to
CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in order to get the compiler tests to use
the right flags? If I add the -arch flags using ADD_DEFINITIONS(), they
are passed to the compiler test and it succeeds. That seems like a hack and
not a proper solution, though.
Below is the CMake output that prints the values of CMAKE_*_FLAGS as set
by the toolchain file, as well as the compile and link lines used by CMake.
I am using CMake 2.8.3 on Snow Leopard 10.6.5.
CMake Output:
-- CMAKE_C_FLAGS:-arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_CXX_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_C_LINK_FLAGS-arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_CXX_LINK_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_C_FLAGS:-arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_CXX_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_C_LINK_FLAGS-arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- CMAKE_CXX_LINK_FLAGS -arch armv6 -arch armv7 -pipe -no-cpp-precomp
--sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2
-- Check for working C compiler:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -- broken
CMake Error at
/opt/local/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 is
not
able to compile a simple test program.
It fails with the following output:
Change Dir:
/Users/jholewinski/projects/rapture/build-test/ios/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make cmTryCompileExec/fast
/usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
[CMake] INSTALL_NAME_DIR with IMPORTED targets
Is there a way to make CMake honor the INSTALL_NAME_DIR property for
IMPORTED library targets?
For the Mac OS X build of an application, I have a binary-only, third-
party library in the form of a .dylib that I keep in the source tree.
I add it to my CMake build script as such:
ADD_LIBRARY(foo SHARED IMPORTED)
SET_TARGET_PROPERTIES(foo PROPERTIES IMPORTED_LOCATION $
{THIRD_PARTY_LIB})
where THIRD_PARTY_LIB is the path to the library in the source tree.
When I configure the bundle for the application, I add ``foo'' as a
link library with TARGET_LINK_LIBRARIES, e.g.
ADD_EXECUTABLE(myexe MACOSX_BUNDLE sources)
TARGET_LINK_LIBRARIES(myexe foo ${OTHER_LIBRARY_TARGETS})
where OTHER_LIBRARY_TARGETS are additional shared libraries built for
the project.
I install with:
INSTALL(TARGETS myexe DESTINATION .)
INSTALL(TARGETS ${OTHER_LIBRARY_TARGETS} DESTINATION myexe.app/
Contents/MacOS)
INSTALL(FILES ${THIRD_PARTY_LIB})
As is, this builds the app bundle but does not properly adjust
the .dylib paths in the binaries. I can fix this with:
SET_TARGET_PROPERTIES(${OTHER_LIBRARY_TARGETS} PROPERTIES
INSTALL_NAME_DIR @executable_path)
and this works great for the shared libraries built for the project,
but this does *not* work for the IMPORTED library:
SET_TARGET_PROPERTIES(foo PROPERTIES INSTALL_NAME_DIR
@executable_path)
or
SET_TARGET_PROPERTIES(${THIRD_PARTY_LIB} PROPERTIES INSTALL_NAME_DIR
@executable_path)
In either case, ``otool -L'' shows that the third-party library name
is not prepended with @executable_path and hence trying to launch the
bundle as an application fails with an error saying the third-party
library could not be located.
Is there a way to make CMake honor INSTALL_NAME_DIR for IMPORTED
targets, or perhaps a better way of linking against and installing
third-party libraries on Mac OS X using CMake's install provisions? I
could probably use a post-build shell script, but I would like to do
this within the CMake build scripts, if possible.
Thanks!
___
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
[CMake] Using Intel C++ Compiler for Mixed C++/Objective-C++ Project on Mac OS X
I have a project that uses both plain C++ (.cpp) and Objective-C++ (.mm)
sources on Mac OS X. Using the Makefile target of CMake with the native
compiler (GCC) works fine. However, the Intel C++ compiler does not handle
Objective-C++ sources so CMake-generated Makefiles fail when the .mm files
are passed to icc/icpc (the Intel C and C++ compilers). Is there a way to
instruct CMake to use icc/icpc for C/C++ files and gcc for .m/.mm files?
Can this be done without having to rewrite ADD_EXECUTABLE and other macros?
Example:
test.c:
extern void foo();
int main()
{
foo();
return 0;
}
testobjc.m:
#include stdio.h
int foo()
{
printf(foo()\n);
}
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
PROJECT(Test)
ADD_EXECUTABLE(test test.c testobjc.m)
Using GCC:
$ cmake ...
$ make
Scanning dependencies of target test
[ 50%] Building C object CMakeFiles/test.dir/test.c.o
[100%] Building CXX object CMakeFiles/test.dir/testobjc.m.o
Linking CXX executable test
[100%] Built target test
Using ICC:
$ CC=icc CXX=icpc cmake ...
$ make
Scanning dependencies of target test
[ 50%] Building C object CMakeFiles/test.dir/test.c.o
[100%] Building CXX object CMakeFiles/test.dir/testobjc.m.o
icpc: warning #10147: no action performed for specified file(s)
Linking CXX executable test
icpc: error #10236: File not found: 'CMakeFiles/test.dir/testobjc.m.o'
make[2]: *** [test] Error 1
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make: *** [all] Error 2
Desired:
$ icc -fast test.c -o test.o -c
$ gcc -O3 testobjc.m -o testobjc.o -c
$ icc -fast test.o testobjc.o -o test
--
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
