Re: [CMake] cross-compiling for arm
Gunter, Walter E wrote:
> I setup the Main CMakeLists.txt to cross_compile using an arm toolchain:
>
> cmake_minimum_required(VERSION 3.2)
>
> project(enterprise CXX)
>
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_CXX_COMPILER
> /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
> set(CMAKE_SYSTEM_PROCESSOR arm)
>
> set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)
> set(CMAKE_FIND_ROOT_PATH /mnt/root)
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>
> set(COMPILE_FLAGS "-lrt -Wall -lpthread")
>
> find_package(Threads)
>
> add_subdirectory(src)
>
> if(CMAKE_CROSSCOMPILING)
> message("I should be cross compiling: ")
> endif()
>
> #find_package(GTest REQUIRED)
>
>
>
> I made some changes to my cmakelists.txt in my src file :
>
> set(SOURCES ${CMAKE_CURRENT_SOURCE_DIR}
> *list of files*.cpp
> Mainfile.cpp
> Mycan.cpp #this one references the linux/can.h
> )
>
> include_directories("../includes")
> set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
This is not needed, CMake will automatically detect this.
> add_executable(enterprise ${SOURCES})
> target_link_libraries(enterprise ${CMAKE_THREAD_LIBS_INIT} pthread)
pthread is not needed here. If CMAKE_THREAD_LIBS_INIT is empty you probably
have a problem already. Also you should do
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
before find_package(Threads), and ideally
target_link_libraries(enterprise Threads::Threads)
afterwards, as this will also add the -pthread flag to compilation.
I still doubt that you properly use a toolchain file (i.e. "cmake -D
CMAKE_TOOLCHAIN_FILE=my_arm_stuff.cmake …" in a clean build dir).
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cross-compiling for arm
I setup the Main CMakeLists.txt to cross_compile using an arm toolchain:
cmake_minimum_required(VERSION 3.2)
project(enterprise CXX)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_CXX_COMPILER
/opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-g++)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_AR /opt/toolchains/arm-2008q3/bin/arm-none-linux-gnueabi-ar)
set(CMAKE_FIND_ROOT_PATH /mnt/root)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(COMPILE_FLAGS "-lrt -Wall -lpthread")
find_package(Threads)
add_subdirectory(src)
if(CMAKE_CROSSCOMPILING)
message("I should be cross compiling: ")
endif()
#find_package(GTest REQUIRED)
I made some changes to my cmakelists.txt in my src file :
set(SOURCES ${CMAKE_CURRENT_SOURCE_DIR}
*list of files*.cpp
Mainfile.cpp
Mycan.cpp #this one references the linux/can.h
)
include_directories("../includes")
set_source_files_properties(${SOURCES} PROPERTIES LANGUAGE CXX)
add_executable(enterprise ${SOURCES})
target_link_libraries(enterprise ${CMAKE_THREAD_LIBS_INIT} pthread)
I am now getting an error that it can't find a linux can header that is
included in the toolchain:
error: 'PF_CAN' was not declared in this scope
This is referenced in the linux/can.h (a socket can define that is preset)
#include <
-Original Message-
From: Rolf Eike Beer [mailto:e...@sf-mail.de]
Sent: Thursday, September 15, 2016 12:06 PM
To: cmake@cmake.org
Cc: Gunter, Walter E
Subject: Re: [CMake] cross-compiling for arm
Am Donnerstag, 15. September 2016, 15:48:02 schrieb Gunter, Walter E:
> I am using the arm-2008q3 toolchain and having some issues with compiling.
> Doing a c++ compile for RT Linux,
> I have setup the following in my main CMakeLists.txt
Use a toolchain file. project() will scan for the compiler and do all sorts of
setup code, you can never be sure to override enough afterwards. In fact, you
probably can't.
https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
Eike
--
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cross-compiling for arm
Am Donnerstag, 15. September 2016, 15:48:02 schrieb Gunter, Walter E: > I am using the arm-2008q3 toolchain and having some issues with compiling. > Doing a c++ compile for RT Linux, > I have setup the following in my main CMakeLists.txt Use a toolchain file. project() will scan for the compiler and do all sorts of setup code, you can never be sure to override enough afterwards. In fact, you probably can't. https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cross compiling with sdcc
On Saturday, June 13, 2015 23:26:59 tors...@robitzki.de wrote: > Hi Alex, > > Am 13.06.2015 um 22:18 schrieb Alexander Neundorf : > > On Friday, May 29, 2015 11:14:06 tors...@robitzki.de wrote: > … > > >> I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > >> for a way to force cmake to use this file, I found a makro > >> CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > > > … > > you shouldn't have to use cmake_force_c_compiler(). > > You did try setting up a toolchain file which points to sdcc ? > > could you elaborate on this solution? Would the > Platform/Generic-SDCC-C.cmake file that is shipped with a normal cmake > installation such a toolchain file? here is some documentation on this: http://www.cmake.org/cmake/help/v3.2/manual/cmake-toolchains.7.html Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cross compiling with sdcc
Hi Alex, Am 13.06.2015 um 22:18 schrieb Alexander Neundorf : > On Friday, May 29, 2015 11:14:06 tors...@robitzki.de wrote: … >> I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching >> for a way to force cmake to use this file, I found a makro >> CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > … > you shouldn't have to use cmake_force_c_compiler(). > You did try setting up a toolchain file which points to sdcc ? could you elaborate on this solution? Would the Platform/Generic-SDCC-C.cmake file that is shipped with a normal cmake installation such a toolchain file? kind regards, Torsten -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] cross compiling with sdcc
On Friday, May 29, 2015 11:14:06 tors...@robitzki.de wrote: > Hello, > I was looking for some resources on how to configure cmake to use the small > device c compiler (sdcc). I tried a little bit and found that cmake assumed > that the object file extension would be .obj. But sdcc uses .rel for object > files. I’ve searched a lot in the web and the cmake sources, tried to > figure out, how the compiler detection mechanism works. > > I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > for a way to force cmake to use this file, I found a makro > CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > So now I have a working solution and wonder if that solution is one > „correct“ solution. „correct“ in terms of supported and intended by the > developers. > > cmake_minimum_required(VERSION 3.2) > include (CMakeForceCompiler) > set(CMAKE_SYSTEM_NAME Generic) > CMAKE_FORCE_C_COMPILER(sdcc SDCC) > > project(test C) > > Does this looks reasonable? Thank you very much for your time! you shouldn't have to use cmake_force_c_compiler(). You did try setting up a toolchain file which points to sdcc ? Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for Tizen emulator
On Fri 06 Dec 2013 01:04:35 AM CET, Stephen Kelly wrote: Bogdan Cristea wrote: SET(CMAKE_FIND_ROOT_PATH /home/bogdan/dev/src/tizenbuildtools/emulator/GBS-ROOT/local/BUILD- ROOTS/scratch.i586.0) This is not passed as --sysroot. However, cmake master supports a CMAKE_SYSROOT variable. http://www.cmake.org/cmake/help/git-master/variable/CMAKE_SYSROOT.html Please test a master build or a nightly build so that we know CMAKE_SYSROOT works for you. SET(CMAKE_SYSROOT /home/bogdan/dev/src/tizenbuildtools/emulator/GBS-ROOT/local/BUILD- ROOTS/scratch.i586.0) Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake Indeed, the compilers are detected, thank you -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for Tizen emulator
Bogdan Cristea wrote: > SET(CMAKE_FIND_ROOT_PATH > /home/bogdan/dev/src/tizenbuildtools/emulator/GBS-ROOT/local/BUILD- ROOTS/scratch.i586.0) This is not passed as --sysroot. However, cmake master supports a CMAKE_SYSROOT variable. http://www.cmake.org/cmake/help/git-master/variable/CMAKE_SYSROOT.html Please test a master build or a nightly build so that we know CMAKE_SYSROOT works for you. SET(CMAKE_SYSROOT /home/bogdan/dev/src/tizenbuildtools/emulator/GBS-ROOT/local/BUILD- ROOTS/scratch.i586.0) Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cross compiling - CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and link.txt
Jack Smith wrote: > Hello, > > I'm confused by an issue that I am having with a project I have recently > joined. You might consider trying my cross-compiling-toolchain-variables branch in the git repo. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling with Wind River (Diab) compiler
On Monday 27 May 2013, BILODEAU Andre wrote: > Hello > > I am presently installing makefiles for cross-compiling by using cmake > 2.8.10.2 and I have to deal with the following issues: > > 1- The toolchain, Wind River C compiler (formerly Diab) is not > mentioned into modules such as "CMakeDetermineCompilerId.cmake), and the > compiler is not identified Ok, so this toolchain has to be added. This is probably not too complicated. Add a way to recognize the compiler in CMakeDetermineCompilerID, and then add a file for this toolchain in Modules/Compiler/. Somehow I assume that this compiler is probably quite straightforward and similar to other UNIX compilers. > 2- Mandatory project options force to compile in 2 steps: > > a. Firstly, compile compiler (dcc) for producing an assembler file > > b. Then call the assembler (called dar) program for getting the object > file .o Hmm, this is in general not supported. If you really have to do it this way, I'm not sure I can recommend using cmake. The assembler is maybe "das", not "dar" ? > 3- Moreover, I wish to produce a static library by using a specific > Wind River archiver (called dar) No problem, this can be tweaked in CMakeFindBinUtils.cmake. Alex -- 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 from linux to windows using wine-based visual studio compilers
On 2012-10-15 21:46-0700 Daniel Russel wrote: On Oct 15, 2012, at 9:35 PM, "Alan W. Irwin" wrote: On 2012-10-15 21:02-0700 Daniel Russel wrote: I'm trying to get cross compilation of a simple library working to build a windows library on a linux box using the visual studio compilers. I don't get it. How can visual studio compilers execute properly on Linux? Don't they need to be run on a Windows platform? Using Wine. I probably should have mentioned it. Actually you did right in the subject line, but my eyes focussed on cross-compilation and just plain missed it. :-) And perhaps cross-compilation is not quite the right term. Is there a better one? I just call it building software on the Wine platform. We have been using them to compile other projects built with scons. That's cool that the visual studio compilers work with scons on the Wine platform. I think that and my good results with the Windows version of CMake on Wine (albeit with a different Windows compiler) is a pretty good indication that CMake + visual studio compilers will probably work on the Wine platform for you as well. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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 from linux to windows using wine-based visual studio compilers
On Oct 15, 2012, at 9:35 PM, "Alan W. Irwin" wrote: > On 2012-10-15 21:02-0700 Daniel Russel wrote: > >> I'm trying to get cross compilation of a simple library working to > build a windows library on a linux box using the visual studio > compilers. > > I don't get it. How can visual studio compilers execute properly on Linux? > Don't they need to be run on a Windows platform? Using Wine. I probably should have mentioned it. And perhaps cross-compilation is not quite the right term. Is there a better one? We have been using them to compile other projects built with scons. > > Regardless of the answer to that question you might want to try > building your library with the Windows version of CMake and the visual > studio compilers on the Wine Windows platform on Linux. Of course, > that is no longer cross-compiling since you are building your Windows > library directly on a Windows platform (Wine). Good idea. I'll give the windows version of cmake a try. > I have recently had good success with software builds using MinGW/MSYS > and the _Windows version of CMake on Wine. So if visual studio > compilers don't work on Wine because of some Wine incompatibility with > proprietary Windows, you can always move with a fair degree of > confidence to using MinGW/MSYS (and probably MinGW alone if you have > no need for the MSYS tools) on Wine. 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
Re: [CMake] Cross compiling from linux to windows using wine-based visual studio compilers
On 2012-10-15 21:02-0700 Daniel Russel wrote: I'm trying to get cross compilation of a simple library working to build a windows library on a linux box using the visual studio compilers. I don't get it. How can visual studio compilers execute properly on Linux? Don't they need to be run on a Windows platform? Regardless of the answer to that question you might want to try building your library with the Windows version of CMake and the visual studio compilers on the Wine Windows platform on Linux. Of course, that is no longer cross-compiling since you are building your Windows library directly on a Windows platform (Wine). I have recently had good success with software builds using MinGW/MSYS and the _Windows version of CMake on Wine. So if visual studio compilers don't work on Wine because of some Wine incompatibility with proprietary Windows, you can always move with a fair degree of confidence to using MinGW/MSYS (and probably MinGW alone if you have no need for the MSYS tools) on Wine. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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 for Windows x64/amd64 on 32-bit Windows
On Tue, Oct 2, 2012 at 1:09 PM, Arindam Mukherjee wrote: > On Tue, Oct 2, 2012 at 4:22 PM, David Cole wrote: >> >> >> cmake -G "Visual Studio 9 2008 Win32" src_dir >> >> will not work. There is no such generator. Leave out the " Win32" for this >> case... it is implied. >> >> > > How would it be on a Windows x64 box? I don't have access to one. > Would "Visual Studio 9 2008" still mean 32-bit on it? > Yes. VS9 Win32 generator is still called "Visual Studio 9 2008" on a 64-bit Windows. Xavier -- 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 for Windows x64/amd64 on 32-bit Windows
On Tue, Oct 2, 2012 at 4:22 PM, David Cole wrote: > On Tue, Oct 2, 2012 at 5:30 AM, Arindam Mukherjee > wrote: >> >> On Tue, Oct 2, 2012 at 2:48 AM, Xavier Besseron >> wrote: >> > Hi, >> > >> > I was able to build win64 executable on my 32-bit Windows. >> > >> > First, I had to make the "full installation" of VS 2008 (the "default >> > installation" did not provide the win64 compiler in my case). Then, I >> > had to select the "Visual Studio 9 2008 Win64" generator in CMake. And >> > the project built correctly. >> > >> > However, it is not possible to execute the generated binaries on a >> > 32-bit Windows. >> > >> > >> >> Thanks! That works perfectly. From a driver batch script, I now use: >> >> cmake -G "Visual Studio 9 2008 Win32" src_dir >> >> and: >> >> cmake -G "Visual Studio 9 2008 Win64" src_dir >> >> This, I guess, should work even if I move to a 64-bit build machine. >> >> Thanks again. >> Arindam >> -- >> >> 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 -G "Visual Studio 9 2008 Win32" src_dir > > will not work. There is no such generator. Leave out the " Win32" for this > case... it is implied. > > How would it be on a Windows x64 box? I don't have access to one. Would "Visual Studio 9 2008" still mean 32-bit on it? Arindam -- 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 for Windows x64/amd64 on 32-bit Windows
On Tue, Oct 2, 2012 at 5:30 AM, Arindam Mukherjee < arindam.muker...@gmail.com> wrote: > On Tue, Oct 2, 2012 at 2:48 AM, Xavier Besseron > wrote: > > Hi, > > > > I was able to build win64 executable on my 32-bit Windows. > > > > First, I had to make the "full installation" of VS 2008 (the "default > > installation" did not provide the win64 compiler in my case). Then, I > > had to select the "Visual Studio 9 2008 Win64" generator in CMake. And > > the project built correctly. > > > > However, it is not possible to execute the generated binaries on a > > 32-bit Windows. > > > > > > Thanks! That works perfectly. From a driver batch script, I now use: > > cmake -G "Visual Studio 9 2008 Win32" src_dir > > and: > > cmake -G "Visual Studio 9 2008 Win64" src_dir > > This, I guess, should work even if I move to a 64-bit build machine. > > Thanks again. > Arindam > -- > > 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 -G "Visual Studio 9 2008 Win32" src_dir will not work. There is no such generator. Leave out the " Win32" for this case... it is implied. HTH, David -- 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 for Windows x64/amd64 on 32-bit Windows
On Tue, Oct 2, 2012 at 2:48 AM, Xavier Besseron wrote: > Hi, > > I was able to build win64 executable on my 32-bit Windows. > > First, I had to make the "full installation" of VS 2008 (the "default > installation" did not provide the win64 compiler in my case). Then, I > had to select the "Visual Studio 9 2008 Win64" generator in CMake. And > the project built correctly. > > However, it is not possible to execute the generated binaries on a > 32-bit Windows. > > Thanks! That works perfectly. From a driver batch script, I now use: cmake -G "Visual Studio 9 2008 Win32" src_dir and: cmake -G "Visual Studio 9 2008 Win64" src_dir This, I guess, should work even if I move to a 64-bit build machine. Thanks again. Arindam -- 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 for Windows x64/amd64 on 32-bit Windows
Hi, I was able to build win64 executable on my 32-bit Windows. First, I had to make the "full installation" of VS 2008 (the "default installation" did not provide the win64 compiler in my case). Then, I had to select the "Visual Studio 9 2008 Win64" generator in CMake. And the project built correctly. However, it is not possible to execute the generated binaries on a 32-bit Windows. Xavier On Mon, Oct 1, 2012 at 10:45 PM, John Drescher wrote: > On Mon, Oct 1, 2012 at 4:35 PM, Arindam Mukherjee > wrote: >> Hi, >> >> I have a Windows XP build setup with Visual Studio 2008 SP1 and >> Windows SDK 6. I have set up a CMake project for a source base that is >> built on Linux, Solaris, AIX and Windows. So far I have managed to get >> the Windows 32-bit build going but cannot make the x64 cross-compile >> work. >> >> It seems that CMake generates 32-bit builds even when I initialize the >> 64-bit build system (vcvarsall.bat x64). What is the correct way to >> set such a build up. >> > > I do not believe Visual Studio will build x64 targets on 32 bit > windows. The first issue would be installing the x64 compiler. However > I could be wrong. > > John > -- > > 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 -- 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 for Windows x64/amd64 on 32-bit Windows
On Mon, Oct 1, 2012 at 4:35 PM, Arindam Mukherjee wrote: > Hi, > > I have a Windows XP build setup with Visual Studio 2008 SP1 and > Windows SDK 6. I have set up a CMake project for a source base that is > built on Linux, Solaris, AIX and Windows. So far I have managed to get > the Windows 32-bit build going but cannot make the x64 cross-compile > work. > > It seems that CMake generates 32-bit builds even when I initialize the > 64-bit build system (vcvarsall.bat x64). What is the correct way to > set such a build up. > I do not believe Visual Studio will build x64 targets on 32 bit windows. The first issue would be installing the x64 compiler. However I could be wrong. John -- 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 - Avoiding libraries
Svenskmand wrote:
> Hello :)
>
> I am one of the developers of OpenDungeons a FOSS RTS game inspired by
> Dungeon Keeper. I am trying to cross-compile our game on Ubuntu 12.04 for
> Windows (XP, Vista and 7), but I have run into some trouble.
>
> I following these guides:
> http://www.cmake.org/Wiki/CMake_Cross_Compiling
> http://www.cmake.org/Wiki/CmakeMingw
>
> I use the following external libraries:
>
> Ogre SDK 1.7.2 (MingW)
> https://sourceforge.net/projects/ogre/files/ogre/1.7/OgreSDK_mingw_v1-7-2.ex
> e/download CEGUI SDK 0.7.5 (MingW)
> https://sourceforge.net/projects/crayzedsgui/files/CEGUI%20Mk-2/0.7.5/CEGUI-
> SDK-0.7.5-mingw.zip/download SFML 1.6 (MingW)
> https://sourceforge.net/projects/sfml/files/sfml/1.6/SFML-1.6-dev-windows-mi
> ngw.zip/download
>
> and have made the following toolchain file (Toolchain.cmake):
>
> # this one is important
> SET(CMAKE_SYSTEM_NAME Windows)
> #this one not so much
> SET(CMAKE_SYSTEM_VERSION 1)
>
> # specify the cross compiler
> SET(CMAKE_C_COMPILER /usr/bin/i686-w64-mingw32-gcc)
> SET(CMAKE_CXX_COMPILER /usr/bin/i686-w64-mingw32-g++)
> SET(CMAKE_RC_COMPILER /usr/bin/i686-w64-mingw32-windres)
>
> SET(BOOST_ROOT ${CROSS_DIR}/OgreSDK_mingw_v1-7-2/boost)
> SET(CEGUIOGRE_LIBRARY ${CROSS_DIR}/OgreSDK_mingw_v1-7-2/lib/release)
This one ...
> SET(CEGUI_LIBRARY ${CROSS_DIR}/CEGUI/lib)
> SET(CEGUI_INCLUDE_DIR ${CROSS_DIR}/CEGUI/cegui/include)
> SET(OPENAL_LIBRARY ${CROSS_DIR}/SFML-1.6/lib)
... and this one are directories AFAICT, but you need to name a library here I
guess. So appending something like "/libOpenAL.lib" or however that thing is
called may solve your problem.
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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 - Avoiding libraries
On Wednesday 18 July 2012, Svenskmand wrote: > Hello :) > > I am one of the developers of OpenDungeons a FOSS RTS game inspired by > Dungeon Keeper. I am trying to cross-compile our game on Ubuntu 12.04 for > Windows (XP, Vista and 7), but I have run into some trouble. ... > SVN/mediaSource/ODLinuxBuildScripts/build_dir/CEGUI/lib". Targets may link > only to libraries. CMake is dropping the item. > WARNING: Target "OpenDungeons" requests linking to directory > "/home/ckr/Documents/OD > SVN/mediaSource/ODLinuxBuildScripts/build_dir/OgreSDK_mingw_v1-7-2/lib/rele > ase". Targets may link only to libraries. CMake is dropping the item. > -- Generating done > -- Build files have been written to: /home/ckr/Documents/OD > SVN/mediaSource/ODLinuxBuildScripts/build_dir/opendungeons-0.4.9 > > Which I am not sure are important or not (but that is not my question for > now). Can you try to produce a small testcase which you can post here ? I have never seen that message before. Alex -- 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 in Win32 environment doesn't work
Hi Alex,
sorry for sending mails in HTML format (hopefully the mail client is now
configured correctly).
You'll find my answers to your comments below.
On 20.09.11 05:29, Alexander Neundorf wrote:
Hi,
can you please adjust your mail client so it doesn't send HTML mails ?
On Monday, September 19, 2011 04:57:32 PM Martin Kupke wrote:
That's a hint, I changed my toolchain file "toolchain_ppc.cmake" to the
following: INCLUDE(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME "Discovery")
if(CMAKE_CROSSCOMPILING)
message("Cross Compiling")
endif(CMAKE_CROSSCOMPILING)
# which compilers to use for C and C++
set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
Then I created a folder with the name Platform containing a file with
CMAKE_SYSTEM_NAME which is Discovery -> at this point I had already
problems, because CMake doesn't use as described the filename with .cmake
extension. The filename in the Platform folder has to have the name from
CMAKE_SYSTEM_NAME without the extension .cmake (even the documentation
says something different). I checked this by adding the output of a
message("SYSTEM_NAME=Discovery").
The filename must be Discovery.cmake in your case.
Did you say this didn't work ?
This file must be either in the cmake Modules/Platfom/ directory, or in a
subdirectory Platform/ of a directory which is in CMAKE_MODULE_PATH.
Yes, I created the folder Platform in my CMAKE_MODULE_PATH and within
this folder the file Discovery.cmake.
This doesn't work! I checked it using the message tag to output a string
on the console.
After renaming the Discovery.cmake to only basename Discovery without
the extension .cmake, the file was included.
So, the extension .cmake isn't correct...even it is described in the
documentation.
The output of the CMake tool, if using the CMAKE_SYSTEM_NAME set to
"Discovery":
### snip ###
D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake
Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
Cross Compiling
-- The C compiler identification is unknown
-- Check for working C compiler: c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
System is unknown to cmake, create:
Platform/Discovery to use this system, please send your config file to
cm...@www.cmake.org so it can be added to cmake
-- Check for working C compiler:
c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe --works
-- Detecting C compiler ABI info
System is unknown to cmake, create:
Platform/Discovery to use this system, please send your config file to
cm...@www.cmake.org so it can be added to cmake
-- Detecting C compiler ABI info - done
C compiler: c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
C flags: -tPPCVLEEN:simple
Mein CMakeLists.txt File
-- Configuring done
-- Generating done
-- Build files have been written to:
D:/novero/Discovery/impl/target/CarIF_Appl/output
### snap ###
It seems to work, even there are some hints that CMake doesn't know the
system Discovery.
I fixed the problem by using the CMAKE_SYSTEM_NAME set to "Generic".
With "Generic" I need a configuration file in the Platform folder named
to "Generic-dcc" with the compile flags.
The name in the Platform folder again is used without the extension .cmake!
"Generic" needs to be added with "-dcc" because of the Base name of the
dcc.exe compiler.
This now works and creates the Makefile in the output folder as wanted,
without any errors / warnings ...
The Platform/Discovery file contains the lines:
message("SYSTEM_NAME=Discovery")
set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
set(CMAKE_FORCE_C_FLAGS "-tPPCVLEEN:simple")
set(CMAKE_FORCE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_FLAGS
"-tPPCVLEEN:simple")
set(CMAKE_MAKE_PROGRAM "D:/novero/Discovery/impl/win32/nmake/nmake.exe")
That last line should not be necessary.
I thought this would help to point to the nmake tool in the Makefile, in
case it is not in the search path of the system.
Then I call from the command line the CMake tool with the parameters:
D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake
Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
The following output will be produced:
* snip output *
Cross Compiling
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
SYSTEM_NAME=Discovery
SYSTEM_NAME=Discovery
-- Check for working C compiler:
C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe System is unknown to cmake,
create:
Platform/Discovery to use this system,
Re: [CMake] Cross compiling in Win32 environment doesn't work
Hi,
can you please adjust your mail client so it doesn't send HTML mails ?
On Monday, September 19, 2011 04:57:32 PM Martin Kupke wrote:
> That's a hint, I changed my toolchain file "toolchain_ppc.cmake" to the
> following: INCLUDE(CMakeForceCompiler)
> set(CMAKE_SYSTEM_NAME "Discovery")
>
> if(CMAKE_CROSSCOMPILING)
> message("Cross Compiling")
> endif(CMAKE_CROSSCOMPILING)
>
> # which compilers to use for C and C++
> set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
> set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
> set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
>
> Then I created a folder with the name Platform containing a file with
> CMAKE_SYSTEM_NAME which is Discovery -> at this point I had already
> problems, because CMake doesn't use as described the filename with .cmake
> extension. The filename in the Platform folder has to have the name from
> CMAKE_SYSTEM_NAME without the extension .cmake (even the documentation
> says something different). I checked this by adding the output of a
> message("SYSTEM_NAME=Discovery").
The filename must be Discovery.cmake in your case.
Did you say this didn't work ?
This file must be either in the cmake Modules/Platfom/ directory, or in a
subdirectory Platform/ of a directory which is in CMAKE_MODULE_PATH.
> The Platform/Discovery file contains the lines:
> message("SYSTEM_NAME=Discovery")
> set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
> set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
> set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
> set(CMAKE_FORCE_C_FLAGS "-tPPCVLEEN:simple")
> set(CMAKE_FORCE_CXX_COMPILER
> "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_COMPILER
> "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_FLAGS
> "-tPPCVLEEN:simple")
> set(CMAKE_MAKE_PROGRAM "D:/novero/Discovery/impl/win32/nmake/nmake.exe")
That last line should not be necessary.
> Then I call from the command line the CMake tool with the parameters:
> D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake
> Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
>
> The following output will be produced:
> * snip output *
> Cross Compiling
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> SYSTEM_NAME=Discovery
> SYSTEM_NAME=Discovery
> -- Check for working C compiler:
> C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe System is unknown to cmake,
> create:
> Platform/Discovery to use this system, please send your config file to
> cmake@www .cmake.org so it can be added to cmake
> -- Check for working C compiler:
> C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe -- broken
> CMake Error at C:/Program Files/CMake
> 2.8/share/cmake-2.8/Modules/CMakeTestCComp iler.cmake:52 (MESSAGE):
>The C compiler "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe" is not able
> to compile a simple test program.
>
>It fails with the following output:
>
> Change Dir:
> D:/novero/Discovery/impl/target/CarIF_Appl/output/CMakeFiles/CMak eTmp
>
>Run Build Command:nmake /NOLOGO "cmTryCompileExec\fast"
>
> nmake -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L
>CMakeFiles\cmTryCompileExec.dir\build
>
> "C:\Program Files\CMake 2.8\bin\cmake.exe" -E
> cmake_progress_report
> D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\CMak
> eFil es
>1
>
>Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj
>
> C:\WindRiver\diab\5.9.0.0\WIN32\bin\dcc.exe -o
>CMakeFiles\cmTryCompileExec.dir\testCCompiler.c.obj -c
>
> D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\test
> CCom piler.c
>
>
>Target Unknown. Use the -t option or set a default target with dctrl -t
>
>NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
>'0x1'
>
>Stop.
>
>NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
>'0x2'
>
>Stop.
>
>CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>CMakeLists.txt:2 (project)
>
>
> -- Configuring incomplete, errors occurred!
> You have changed variables that require your cache to be deleted.
> Configure will be re-run and you may have to reset some variables.
> The following variables have changed:
> CMAKE_CXX_COMPILER= cl
>
> -- Generating done
> -- Build files have been written to:
> D:/novero/Discovery/impl/target/CarIF_Appl/ output
>
> * snap output *
>
> 1.) with the output SYSTEM_NAME=Discovery I can see that the platform file
> is used 2.) the compilation doesn't complete, because the CMAKE_C_FLAGS
> are still not used
They are initialized later on.
There is a set of variables which are used for initialization, I think it's
name is CMAKE_C_FLAGS_INIT .
> 3.) why do I
Re: [CMake] Cross compiling in Win32 environment doesn't work
That's a hint, I changed my toolchain file "toolchain_ppc.cmake" to
the following:
INCLUDE(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME "Discovery")
if(CMAKE_CROSSCOMPILING)
message("Cross Compiling")
endif(CMAKE_CROSSCOMPILING)
# which compilers to use for C and C++
set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_FORCE_C_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
Then I created a folder with the name Platform containing a file
with CMAKE_SYSTEM_NAME which is Discovery -> at this point I had
already problems, because CMake doesn't use as described the
filename with .cmake extension. The filename in the Platform folder
has to have the name from CMAKE_SYSTEM_NAME without the extension
.cmake (even the documentation says something different). I checked
this by adding the output of a message("SYSTEM_NAME=Discovery").
The Platform/Discovery file contains the lines:
message("SYSTEM_NAME=Discovery")
set(CMAKE_FORCE_C_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
set(CMAKE_FORCE_C_FLAGS "-tPPCVLEEN:simple")
set(CMAKE_FORCE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_CXX_FLAGS "-tPPCVLEEN:simple")
set(CMAKE_MAKE_PROGRAM
"D:/novero/Discovery/impl/win32/nmake/nmake.exe")
Then I call from the command line the CMake tool with the
parameters:
D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake
Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
The following output will be produced:
* snip output *
Cross Compiling
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
SYSTEM_NAME=Discovery
SYSTEM_NAME=Discovery
-- Check for working C compiler:
C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
System is unknown to cmake, create:
Platform/Discovery to use this system, please send your config file
to cmake@www
.cmake.org so it can be added to cmake
-- Check for working C compiler:
C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe --
broken
CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCComp
iler.cmake:52 (MESSAGE):
The C compiler "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe" is
not able to
compile a simple test program.
It fails with the following output:
Change Dir:
D:/novero/Discovery/impl/target/CarIF_Appl/output/CMakeFiles/CMak
eTmp
Run Build Command:nmake /NOLOGO "cmTryCompileExec\fast"
nmake -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo
-L
CMakeFiles\cmTryCompileExec.dir\build
"C:\Program Files\CMake 2.8\bin\cmake.exe" -E
cmake_progress_report
D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\CMakeFil
es
1
Building C object
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj
C:\WindRiver\diab\5.9.0.0\WIN32\bin\dcc.exe -o
CMakeFiles\cmTryCompileExec.dir\testCCompiler.c.obj -c
D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\testCCom
piler.c
Target Unknown. Use the -t option or set a default target with
dctrl -t
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return
code
'0x1'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return
code
'0x2'
Stop.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= cl
-- Generating done
-- Build files have been written to:
D:/novero/Discovery/impl/target/CarIF_Appl/
output
* snap output *
1.) with the output SYSTEM_NAME=Discovery I can see that the
platform file is used
2.) the compilation doesn't complete, because the CMAKE_C_FLAGS are
still not used
3.) why do I have to have a CXX (C++) compiler, even if I don't need
it in my embedded solution
4.) is there any reason why CMake needs to know my system? I want
just to compile some files... (wondering)
On 19.09.11 15:46, Eric Noulard wrote:
2011/9/19 Martin Kupke
Re: [CMake] Cross compiling in Win32 environment doesn't work
You can use the following commands to know what are compilers used in
the CMakeLists.txt:
message("C compiler: " ${CMAKE_C_COMPILER})
message("C++ compiler: " ${CMAKE_CXX_COMPILER})
Moreover, you can set them:
set(CMAKE_CXX_COMPILER ...)
regards
Benjamin JEANTY-RUARD
Le lundi 19 septembre 2011 à 14:44 +0200, Martin Kupke a écrit :
> I'm using CMake in version 2.8.5 and just want to cross compile with a
> decicated Compiler / Linker set on my Windows machine. Of course I've
> read the FAQ and the Tutorial, afterwards I started trying to use CMake
> on a DOS (cmd.exe) command line interface with CMakeLists.txt and a
> toolchain file. After all tests failed to get CMake work in the Win32
> environment, I tried it in my private Linux (Debian Squeeze) and the
> same procedure is successful. In Linux environment it works as
> described, in Win32 not.
>
> My PC has installed Windows XP including SP3.
> CMake version 2.8.5 is installed.
> My development path contains a CMakeLists.txt and a toolchain_ppc.cmake
> file, because I want to compile on my WinXP code for an embedded
> hardware using a PPC processor.
> The toolchain_ppc.cmake file contains the following settings:
> set (CMAKE_GENERATOR "NMake Makefiles")
> set (CMAKE_SYSTEM_NAME "Generic")
> set (CMAKE_C_COMPILER "dcc.exe")
> set (CMAKE_SYSTEM_PROCESSOR "ppc")
>
> if(CMAKE_CROSSCOMPILING)
> message("Cross Compiling")
> endif(CMAKE_CROSSCOMPILING)
>
> set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
> set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
>
> In my build environment I created an empty folder output and in the
> command line interface (console / cmd.exe) I'm calling the cmake tool:
> D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -D
> CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
> The output of the cmake tool always is:
> -- Building for: Visual Studio 10
> Cross Compiling
>
> As you can see my message "Cross Compiling" is shown, this introduces
> that cmake is using the "CMAKE_CROSSCOMPILING" flag. But why the hell is
> there always the output "-- Building for: Visual Studio 10"?
> I don't wan't to use anything from / for Visual Studio 10.
>
> The CMakeOutput.log contains the following lines:
> The target system is: Generic - - ppc
> The host system is: Windows - 5.1 - x86
> Compiling the C compiler identification source file "CMakeCCompilerId.c"
> succeeded.
> Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
> Build flags: -tPPCVLEEN:simple
> Id flags:
>
> The output was:
> 0
>
>
> Compilation of the C compiler identification source "CMakeCCompilerId.c"
> produced "a.out"
>
> Compiling the C compiler identification source file "CMakeCCompilerId.c"
> succeeded.
> Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
> Build flags: -tPPCVLEEN:simple
> Id flags: -c
>
> The output was:
> 0
>
>
> Compilation of the C compiler identification source "CMakeCCompilerId.c"
> produced "CMakeCCompilerId.o"
>
> Compiling the CXX compiler identification source file
> "CMakeCXXCompilerId.cpp" succeeded.
> Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
> Build flags: -tPPCVLEEN:simple
> Id flags:
>
> The output was:
> 0
>
>
> Compilation of the CXX compiler identification source
> "CMakeCXXCompilerId.cpp" produced "a.out"
>
> Compiling the CXX compiler identification source file
> "CMakeCXXCompilerId.cpp" succeeded.
> Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
> Build flags: -tPPCVLEEN:simple
> Id flags: -c
>
> The output was:
> 0
>
>
> Compilation of the CXX compiler identification source
> "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o"
>
> Determining if the C compiler works passed with the following output:
> Change Dir:
> D:/novero/Discovery/impl/target/CarIF_Appl/output/CMakeFiles/CMakeTmp
>
> Run Build Command:C:\PROGRA~1\MICROS~2.0\Common7\IDE\devenv.com
> CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec
>
>
> Microsoft (R) Visual Studio Version 10.0.30319.1.
>
> Copyright (C) Microsoft Corp. All rights reserved.
>
> 1>-- Build started: Project: cmTryCompileExec, Configuration: Debug
> Win32 --
>
> 1> testCCompiler.c
>
> 1>C:\Program
> Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
> warning MSB8012:
> TargetPath(D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec)
>
> does not match the Linker's OutputFile property value
> (D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe).
>
> This may cause your project to build incorrectly. To correct this,
> please make sure that $(OutDir), $(TargetName) and $(TargetExt) property
> values match the value specified in %(Link.OutputFile).
>
> 1> cmTryCompileExec.vcxproj ->
> D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec
>
> == Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==
>
>
>
> Detecti
Re: [CMake] Cross compiling in Win32 environment doesn't work
2011/9/19 Martin Kupke
>
> My problem (the error) already occurs in the toolchain file, this means
> before the CMakeLists.txt is read. So far it is total independent of the
> entries in the CMakeLists.txt!
>
> I have added the line:
> message ("Mein CMakeLists.txt File")
> in top of my CMakeLists.txt and would assume that there is an output on the
> console with the string, but it isn't.
>
> The output is stopped while parsing the toolchain file and determining the
> compiler.
That's what I was about to say.
Read http://www.vtk.org/Wiki/CMake_Cross_Compiling carefully
you'll see that you may have to write a
Platform/${CMAKE_SYSTEM_NAME}-.cmake file
in order to inform CMake about your particular compiler compilation FLAGS.
Doing it in CMakeLists.txt may already be too late.
Nevertheless it puzzles me that it works on Linux and not on Windows...
I'm no expert concerning Cross-compiling with CMake so I let others
take over this discussion.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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 in Win32 environment doesn't work
My problem (the error) already occurs in the toolchain file, this
means before the CMakeLists.txt is read. So far it is total
independent of the entries in the CMakeLists.txt!
I have added the line:
message ("Mein CMakeLists.txt File")
in top of my CMakeLists.txt and would assume that there is an output
on the console with the string, but it isn't.
The output is stopped while parsing the toolchain file and
determining the compiler.
On 19.09.11 15:26, Benjamin Ruard wrote:
You can use the following commands to know what are compilers used in
the CMakeLists.txt:
message("C compiler: " ${CMAKE_C_COMPILER})
message("C++ compiler: " ${CMAKE_CXX_COMPILER})
Moreover, you can set them:
set(CMAKE_CXX_COMPILER ...)
regards
Benjamin JEANTY-RUARD
Le lundi 19 septembre 2011 à 14:44 +0200, Martin Kupke a écrit :
I'm using CMake in version 2.8.5 and just want to cross compile with a
decicated Compiler / Linker set on my Windows machine. Of course I've
read the FAQ and the Tutorial, afterwards I started trying to use CMake
on a DOS (cmd.exe) command line interface with CMakeLists.txt and a
toolchain file. After all tests failed to get CMake work in the Win32
environment, I tried it in my private Linux (Debian Squeeze) and the
same procedure is successful. In Linux environment it works as
described, in Win32 not.
My PC has installed Windows XP including SP3.
CMake version 2.8.5 is installed.
My development path contains a CMakeLists.txt and a toolchain_ppc.cmake
file, because I want to compile on my WinXP code for an embedded
hardware using a PPC processor.
The toolchain_ppc.cmake file contains the following settings:
set (CMAKE_GENERATOR "NMake Makefiles")
set (CMAKE_SYSTEM_NAME "Generic")
set (CMAKE_C_COMPILER "dcc.exe")
set (CMAKE_SYSTEM_PROCESSOR "ppc")
if(CMAKE_CROSSCOMPILING)
message("Cross Compiling")
endif(CMAKE_CROSSCOMPILING)
set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
In my build environment I created an empty folder output and in the
command line interface (console / cmd.exe) I'm calling the cmake tool:
D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -D
CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..
The output of the cmake tool always is:
-- Building for: Visual Studio 10
Cross Compiling
As you can see my message "Cross Compiling" is shown, this introduces
that cmake is using the "CMAKE_CROSSCOMPILING" flag. But why the hell is
there always the output "-- Building for: Visual Studio 10"?
I don't wan't to use anything from / for Visual Studio 10.
The CMakeOutput.log contains the following lines:
The target system is: Generic - - ppc
The host system is: Windows - 5.1 - x86
Compiling the C compiler identification source file "CMakeCCompilerId.c"
succeeded.
Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
Build flags: -tPPCVLEEN:simple
Id flags:
The output was:
0
Compilation of the C compiler identification source "CMakeCCompilerId.c"
produced "a.out"
Compiling the C compiler identification source file "CMakeCCompilerId.c"
succeeded.
Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
Build flags: -tPPCVLEEN:simple
Id flags: -c
The output was:
0
Compilation of the C compiler identification source "CMakeCCompilerId.c"
produced "CMakeCCompilerId.o"
Compiling the CXX compiler identification source file
"CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
Build flags: -tPPCVLEEN:simple
Id flags:
The output was:
0
Compilation of the CXX compiler identification source
"CMakeCXXCompilerId.cpp" produced "a.out"
Compiling the CXX compiler identification source file
"CMakeCXXCompilerId.cpp" succeeded.
Compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
Build flags: -tPPCVLEEN:simple
Id flags: -c
The output was:
0
Compilation of the CXX compiler identification source
"CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o"
Determining if the C compiler works passed with the following output:
Change Dir:
D:/novero/Discovery/impl/target/CarIF_Appl/output/CMakeFiles/CMakeTmp
Run Build Command:C:\PROGRA~1\MICROS~2.0\Common7\IDE\devenv.com
CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec
Microsoft (R) Visual Studio Version 10.0.30319.1.
Copyright (C) Microsoft Corp. All rights reserved.
1>-- Build started: Project: cmTryCompileExec, Configuration: Debug
Win32 --
1> testCCompiler.c
1>C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
warning MSB8012:
TargetPath(D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec)
does not match the Linker's OutputFile property value
(D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe).
This may cause your project to build incorrectly. To correct this,
please make sure that $(OutDir), $(TargetNam
Re: [CMake] Cross compiling in Win32 environment doesn't work
If adding the parameter -G "NMake Makefiles" to my command line, then the output is different...but still errors: * snip output * Cross Compiling -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- Check for working C compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe -- Check for working C compiler: C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCComp iler.cmake:52 (MESSAGE): The C compiler "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: D:/novero/Discovery/impl/target/CarIF_Appl/output/CMakeFiles/CMak eTmp Run Build Command:nmake /NOLOGO "cmTryCompileExec\fast" nmake -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec.dir\build "C:\Program Files\CMake 2.8\bin\cmake.exe" -E cmake_progress_report D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\CMakeFil es 1 Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj C:\WindRiver\diab\5.9.0.0\WIN32\bin\dcc.exe -o CMakeFiles\cmTryCompileExec.dir\testCCompiler.c.obj -c D:\novero\Discovery\impl\target\CarIF_Appl\output\CMakeFiles\CMakeTmp\testCCom piler.c Target Unknown. Use the -t option or set a default target with dctrl -t NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2' Stop. * snap output * As you can see above, now the CMAKE_C_FLAGS are not recognized. set(CMAKE_C_FLAGS "-tPPCVLEEN:simple") On 19.09.11 15:24, Eric Noulard wrote: 2011/9/19 Martin Kupke : I'm using CMake in version 2.8.5 and just want to cross compile with a decicated Compiler / Linker set on my Windows machine. Of course I've read the FAQ and the Tutorial, afterwards I started trying to use CMake on a DOS (cmd.exe) command line interface with CMakeLists.txt and a toolchain file. After all tests failed to get CMake work in the Win32 environment, I tried it in my private Linux (Debian Squeeze) and the same procedure is successful. In Linux environment it works as described, in Win32 not. My PC has installed Windows XP including SP3. CMake version 2.8.5 is installed. My development path contains a CMakeLists.txt and a toolchain_ppc.cmake file, because I want to compile on my WinXP code for an embedded hardware using a PPC processor. The toolchain_ppc.cmake file contains the following settings: set (CMAKE_GENERATOR "NMake Makefiles") I'm not sure whether if CMAKE_GENERATOR can be set in the toolchain file? [...] D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" .. did you try to add '-G "NMake Makefiles"' to your command line? [...] I just want to use a standard Assembler, C Compiler and Linker. I don't need CXX (C++) in my build environment and even I don't need (want) any Visual Studio in my Cross Compilation. The generator for CMake shall be "NMake Makefiles" so that the generated Makefile can be used with "NMake". Hopefully you can help me out of this. ___ 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 -- martin kupke can diagnostics engineer | senior software developer m: +49.151.5511.3632 | e: martin.ku...@novero.com skype: martin.kupke_novero | w: www.novero.com meesmannstr.103 | 44807 Bochum | germany novero gmbh | parsevalstr. 7 a | 40468 düsseldorf | germany | amtsgericht düsseldorf | hrb 58283 | umsatzsteueridentifikationsnummer: de 814973142 | geschäftsführender gesellschafter: razvan olosu ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages
Re: [CMake] Cross compiling in Win32 environment doesn't work
2011/9/19 Martin Kupke : > I'm using CMake in version 2.8.5 and just want to cross compile with a > decicated Compiler / Linker set on my Windows machine. Of course I've read > the FAQ and the Tutorial, afterwards I started trying to use CMake on a DOS > (cmd.exe) command line interface with CMakeLists.txt and a toolchain file. > After all tests failed to get CMake work in the Win32 environment, I tried > it in my private Linux (Debian Squeeze) and the same procedure is > successful. In Linux environment it works as described, in Win32 not. > > My PC has installed Windows XP including SP3. > CMake version 2.8.5 is installed. > My development path contains a CMakeLists.txt and a toolchain_ppc.cmake > file, because I want to compile on my WinXP code for an embedded hardware > using a PPC processor. > The toolchain_ppc.cmake file contains the following settings: > set (CMAKE_GENERATOR "NMake Makefiles") I'm not sure whether if CMAKE_GENERATOR can be set in the toolchain file? [...] > D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -D > CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" .. did you try to add '-G "NMake Makefiles"' to your command line? [...] > I just want to use a standard Assembler, C Compiler and Linker. > I don't need CXX (C++) in my build environment and even I don't need (want) > any Visual Studio in my Cross Compilation. > The generator for CMake shall be "NMake Makefiles" so that the generated > Makefile can be used with "NMake". > > Hopefully you can help me out of this. > > > ___ > 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 > -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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 with cmake 2.8.5
On 07/27/2011 04:28 PM, r.cze...@esa-grimma.de wrote: > Hi all, > > I tried to cross-compile an internal application for windows on a linux > machine, > but failed, because cmake at some point re-start the configure process, > and > drops the CMAKE_SYSTEM_NAME variable along that way. Attached is a > minimal CMakeLists.txt, which reproduces the problem. > > Is there a way to avoid the reconfiguration? > > TIA > R. Czerny > > > Console output: > someone@debian-vm:~/cross/build$ cmake -DCMAKE_SYSTEM_NAME=Windows > -DCMAKE_C_COMPILER=i586-mingw32msvc-gcc > -DCMAKE_RC_COMPILER=i586-mingw32msvc-windres .. > -- The C compiler identification is GNU > -- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc > -- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- CC=TRUE CSN=Windows > -- Configuring done > You have changed variables that require your cache to be deleted. > Configure will be re-run and you may have to reset some variables. > The following variables have changed: > CMAKE_RC_COMPILER= i586-mingw32msvc-windres > > -- The C compiler identification is GNU > -- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc > -- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- CC=FALSE CSN=Linux > -- Configuring done > -- Generating done > -- Build files have been written to: /home/czerny/Quellen/hospec/foo/foo When reconfiguring an already configured project, specifying certain variables like CMAKE_C_COMPILER invalidates the cache and makes CMake do another reconfiguration during which the command line settings are lost, CMAKE_SYSTEM_NAME in your case; cf. [1-3]. AFAIK, the best you can do is to use one build tree per toolchain from the first and specify compilers by the environment variables CC, CXX, FC etc. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg34486.html [2] http://www.mail-archive.com/cmake@cmake.org/msg37060.html [3] http://public.kitware.com/Bug/view.php?id=9980 ___ 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 with cmake 2.8.5
On Wednesday 27 July 2011, r.cze...@esa-grimma.de wrote: > Hi all, > > I tried to cross-compile an internal application for windows on a linux > machine, > but failed, because cmake at some point re-start the configure process, > and > drops the CMAKE_SYSTEM_NAME variable along that way. Attached is a > minimal CMakeLists.txt, which reproduces the problem. > > Is there a way to avoid the reconfiguration? Did you try to use a toolchain file as described in the cmake cross compiling wiki page ? http://www.vtk.org/Wiki/CMake_Cross_Compiling It even has a separate link for mingw. Without it, the CMAKE_SYSTEM_NAME you have set via -D probably doesn't make it into the try_compile()-projects. Alex ___ 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 with cmake 2.8.5
2011/7/27 : > Hi all, > > I tried to cross-compile an internal application for windows on a linux > machine, > but failed, because cmake at some point re-start the configure process, and > drops the CMAKE_SYSTEM_NAME variable along that way. Attached is a > minimal CMakeLists.txt, which reproduces the problem. > > Is there a way to avoid the reconfiguration? > > TIA > R. Czerny > > > Console output: > someone@debian-vm:~/cross/build$ cmake -DCMAKE_SYSTEM_NAME=Windows > -DCMAKE_C_COMPILER=i586-mingw32msvc-gcc > -DCMAKE_RC_COMPILER=i586-mingw32msvc-windres .. Did you read this http://www.cmake.org/Wiki/CMake_Cross_Compiling and if yes why didn't you use a toolchain file? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
On Wed, Feb 23, 2011 at 11:28 AM, Alexander Neundorf
wrote:
> On Wednesday 23 February 2011, Schmid Alexander wrote:
>> > This suffix should be set by the platform file.
>> > Modules/CMakeSystemSpecificInformation.cmake includes
>> > CMakeGenericSystem.cmake, which sets it to "". That's what you see.
>> >
>> > Then it includes Platform/${CMAKE_SYSTEM_NAME}, which is
>> > Platform/Generic.cmake. This file does not change the suffix, so it stays
>> > empty for you.
>> >
>> > If you need a different suffix, you probably have to come up with a name
>> > for your platform and provide a platform file for it, which sets the
>> > name.
>> >
>> > Alex
>>
>> Hi Alex,
>>
>> thanks a lot. That was the solution to my problem.
>> Although, I still wonder whether I should have set the suffixes (see David
>> Cole's posting...)
>
> The suffix is meant to be set from the platform file, but not from anywhere
> else.
> So, there are no contradictions here.
>
> Alex
>
Sorry about that. I am not a big cross-compiler yet, and did not
understand that the context of this set call was in a platform file.
Always listen to Alex over me when cross-compling is involved... :-)
___
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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
On Wednesday 23 February 2011, Schmid Alexander wrote:
> > This suffix should be set by the platform file.
> > Modules/CMakeSystemSpecificInformation.cmake includes
> > CMakeGenericSystem.cmake, which sets it to "". That's what you see.
> >
> > Then it includes Platform/${CMAKE_SYSTEM_NAME}, which is
> > Platform/Generic.cmake. This file does not change the suffix, so it stays
> > empty for you.
> >
> > If you need a different suffix, you probably have to come up with a name
> > for your platform and provide a platform file for it, which sets the
> > name.
> >
> > Alex
>
> Hi Alex,
>
> thanks a lot. That was the solution to my problem.
> Although, I still wonder whether I should have set the suffixes (see David
> Cole's posting...)
The suffix is meant to be set from the platform file, but not from anywhere
else.
So, there are no contradictions here.
Alex
___
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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
> This suffix should be set by the platform file.
> Modules/CMakeSystemSpecificInformation.cmake includes
> CMakeGenericSystem.cmake, which sets it to "". That's what you see.
>
> Then it includes Platform/${CMAKE_SYSTEM_NAME}, which is
> Platform/Generic.cmake. This file does not change the suffix, so it stays
> empty for you.
>
> If you need a different suffix, you probably have to come up with a name for
> your platform and provide a platform file for it, which sets the name.
>
> Alex
Hi Alex,
thanks a lot. That was the solution to my problem.
Although, I still wonder whether I should have set the suffixes (see David
Cole's posting...)
Regards,
Alex
___
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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
On Monday 21 February 2011, Schmid Alexander wrote:
...
> I did some tests and from my point of view you are right - I do not have to
> set it at all. But, nevertheless, the problem stays.
> The crosscompiling toolchain produces binary files with .out suffix, and
> for me it seems that the the TRY_COMPILE macro does not recognize this file
> as the result of the building step. Can you please give me some help what I
> can do to get it working?
This suffix should be set by the platform file.
Modules/CMakeSystemSpecificInformation.cmake includes
CMakeGenericSystem.cmake, which sets it to "". That's what you see.
Then it includes Platform/${CMAKE_SYSTEM_NAME}, which is
Platform/Generic.cmake. This file does not change the suffix, so it stays
empty for you.
If you need a different suffix, you probably have to come up with a name for
your platform and provide a platform file for it, which sets the name.
Alex
___
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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
> -Ursprüngliche Nachricht-
> Von: David Cole [mailto:david.c...@kitware.com]
> Gesendet: Montag, 21. Februar 2011 13:41
> An: Schmid Alexander
> Cc: a.neundorf-w...@gmx.net; cmake@cmake.org
> Betreff: Re: [CMake] Cross-compiling: Cmake compiler and ABI check don´t work
> /
> TRY_COMPILE and EXECUTABLE_SUFFIX problem
>
> On Mon, Feb 21, 2011 at 2:14 AM, Schmid Alexander
> wrote:
> > On Friday 18 February 2011, Schmid Alexander wrote:
> >> Hi,
> >>
> >> of course, I´d like to have you think further about it, so here you go...
> >
> > ;-)
> >
> >> This is the toolchain file I use.
> >> The specialty about is that I want to use the ARMCC as compiler and an
> >> SDK-provided linker tool for linking.
> >>
> >> # this one is important
> >> SET( CMAKE_SYSTEM_NAME Generic )
> >> # this one not so much
> >> SET( CMAKE_SYSTEM_VERSION 1 )
> >>
> >> #
> >> ---
> >>-- # setup local variables used
> >> #
> >> ---
> >>--
> >>
> >> SET( SDK1_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk1" )
> >> message( STATUS "The SDK1 can be found at ${SDK1_ROOT}" )
> >> SET( SDK1_INCLUDE "${SDK1_ROOT}/include" )
> >> STRING( REPLACE "\\" "/" SDK1_INCLUDE ${SDK1_INCLUDE} )
> >> SET( SDK1_LIB "${SDK1_ROOT}/lib" )
> >> STRING( REPLACE "\\" "/" SDK1_LIB ${SDK1_LIB} )
> >>
> >> SET( SDK2_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk2" )
> >> message( STATUS "The SDK2 can be found at ${SDK2_ROOT}" )
> >> SET( SDK2_INCLUDE "${SDK2_ROOT}/include" )
> >> STRING( REPLACE "\\" "/" SDK2_INCLUDE ${SDK2_INCLUDE} )
> >> SET( SDK2_LIB "${SDK2_ROOT}/lib" )
> >> STRING( REPLACE "\\" "/" SDK2_LIB ${SDK2_LIB} )
> >>
> >> SET( RVCT40_BIN "$ENV{RVCT40BIN}" )
> >> message( STATUS "The ARM Tools can be found at ${RVCT40_BIN}" )
> >
> >
> > Does it work if you replace the all the $ENV{}s with hardcoded paths ?
> > Please try that and let me know if it works then, so we can figure out a
> > solution.
> >
> > Alex
> >
> >
> >>>>
> >
> > Hi Alex,
> >
> > replacing doesn´t work.
> > I also did some further investigation and it led me to a different problem,
> > that may
> be the reason for all this.
> >
> > I think that the TRY_COMPILE macro of Cmake does not respect the
> CMAKE_EXECUTABLE_SUFFIX that I have set to ".out".
> > So the TRY_COMPILE does not find the correctly built output file and further
> processing fails.
> >
> > Here´s the output of CMAKE:
> > -- Check for working CXX compiler:
> C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe
> > -- Check for working CXX compiler:
> C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe --
> works
> > -- Detecting CXX compiler ABI info
> > CMake Error: Could not COPY_FILE.
> > OutputFile: ''
> > copyFile:
> 'D:/proj/build/test2/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin'
> >
> > Unable to find executable for try_compile: tried
> "D:/proj/build/test2/CMakeFiles/CMakeTmp/cmTryCompileExec" and "D:/proj/build
> > /test2/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec" and
> "D:/proj/build/test2/CMakeFiles/CMakeTmp/Development/cmTryCompileExec".
> >
> > -- Suffix is:
> > -- Output is:
> >
> > As you can see, I manually added the last to MESSAGEs to the
> CmakeDetermineCompilerAbi.cmake that was shipped with Cmake 2.8.3.
> >
> > When I add the line
> > SET( CMAKE_EXECUTABLE_SUFFIX .out )
> > In that file, the ABI check seems to work. So the big question is how to
> > make
> Cmake use the CMAKE_EXECUTABLE_SUFFIX that was given in the toolchain
> file?
> >
> > Regards,
> > Alex
> >
> > ___
> > 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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
On Mon, Feb 21, 2011 at 2:14 AM, Schmid Alexander wrote:
> On Friday 18 February 2011, Schmid Alexander wrote:
>> Hi,
>>
>> of course, I´d like to have you think further about it, so here you go...
>
> ;-)
>
>> This is the toolchain file I use.
>> The specialty about is that I want to use the ARMCC as compiler and an
>> SDK-provided linker tool for linking.
>>
>> # this one is important
>> SET( CMAKE_SYSTEM_NAME Generic )
>> # this one not so much
>> SET( CMAKE_SYSTEM_VERSION 1 )
>>
>> #
>> ---
>>-- # setup local variables used
>> #
>> ---
>>--
>>
>> SET( SDK1_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk1" )
>> message( STATUS "The SDK1 can be found at ${SDK1_ROOT}" )
>> SET( SDK1_INCLUDE "${SDK1_ROOT}/include" )
>> STRING( REPLACE "\\" "/" SDK1_INCLUDE ${SDK1_INCLUDE} )
>> SET( SDK1_LIB "${SDK1_ROOT}/lib" )
>> STRING( REPLACE "\\" "/" SDK1_LIB ${SDK1_LIB} )
>>
>> SET( SDK2_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk2" )
>> message( STATUS "The SDK2 can be found at ${SDK2_ROOT}" )
>> SET( SDK2_INCLUDE "${SDK2_ROOT}/include" )
>> STRING( REPLACE "\\" "/" SDK2_INCLUDE ${SDK2_INCLUDE} )
>> SET( SDK2_LIB "${SDK2_ROOT}/lib" )
>> STRING( REPLACE "\\" "/" SDK2_LIB ${SDK2_LIB} )
>>
>> SET( RVCT40_BIN "$ENV{RVCT40BIN}" )
>> message( STATUS "The ARM Tools can be found at ${RVCT40_BIN}" )
>
>
> Does it work if you replace the all the $ENV{}s with hardcoded paths ?
> Please try that and let me know if it works then, so we can figure out a
> solution.
>
> Alex
>
>
>
> Hi Alex,
>
> replacing doesn´t work.
> I also did some further investigation and it led me to a different problem,
> that may be the reason for all this.
>
> I think that the TRY_COMPILE macro of Cmake does not respect the
> CMAKE_EXECUTABLE_SUFFIX that I have set to ".out".
> So the TRY_COMPILE does not find the correctly built output file and further
> processing fails.
>
> Here´s the output of CMAKE:
> -- Check for working CXX compiler:
> C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe
> -- Check for working CXX compiler:
> C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe --
> works
> -- Detecting CXX compiler ABI info
> CMake Error: Could not COPY_FILE.
> OutputFile: ''
> copyFile:
> 'D:/proj/build/test2/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin'
>
> Unable to find executable for try_compile: tried
> "D:/proj/build/test2/CMakeFiles/CMakeTmp/cmTryCompileExec" and "D:/proj/build
> /test2/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec" and
> "D:/proj/build/test2/CMakeFiles/CMakeTmp/Development/cmTryCompileExec".
>
> -- Suffix is:
> -- Output is:
>
> As you can see, I manually added the last to MESSAGEs to the
> CmakeDetermineCompilerAbi.cmake that was shipped with Cmake 2.8.3.
>
> When I add the line
> SET( CMAKE_EXECUTABLE_SUFFIX .out )
> In that file, the ABI check seems to work. So the big question is how to make
> Cmake use the CMAKE_EXECUTABLE_SUFFIX that was given in the toolchain file?
>
> Regards,
> Alex
>
> ___
> 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_EXECUTABLE_SUFFIX is not intended to be "settable"... That's
completely unexpected from the CMake development team's point of view.
I'm not surprised that it doesn't work.
Why do you need to set it?
___
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 compiler and ABI check don´t work / TRY_COMPILE and EXECUTABLE_SUFFIX problem
On Friday 18 February 2011, Schmid Alexander wrote:
> Hi,
>
> of course, I´d like to have you think further about it, so here you go...
;-)
> This is the toolchain file I use.
> The specialty about is that I want to use the ARMCC as compiler and an
> SDK-provided linker tool for linking.
>
> # this one is important
> SET( CMAKE_SYSTEM_NAME Generic )
> # this one not so much
> SET( CMAKE_SYSTEM_VERSION 1 )
>
> #
> ---
>-- # setup local variables used
> #
> ---
>--
>
> SET( SDK1_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk1" )
> message( STATUS "The SDK1 can be found at ${SDK1_ROOT}" )
> SET( SDK1_INCLUDE "${SDK1_ROOT}/include" )
> STRING( REPLACE "\\" "/" SDK1_INCLUDE ${SDK1_INCLUDE} )
> SET( SDK1_LIB "${SDK1_ROOT}/lib" )
> STRING( REPLACE "\\" "/" SDK1_LIB ${SDK1_LIB} )
>
> SET( SDK2_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk2" )
> message( STATUS "The SDK2 can be found at ${SDK2_ROOT}" )
> SET( SDK2_INCLUDE "${SDK2_ROOT}/include" )
> STRING( REPLACE "\\" "/" SDK2_INCLUDE ${SDK2_INCLUDE} )
> SET( SDK2_LIB "${SDK2_ROOT}/lib" )
> STRING( REPLACE "\\" "/" SDK2_LIB ${SDK2_LIB} )
>
> SET( RVCT40_BIN "$ENV{RVCT40BIN}" )
> message( STATUS "The ARM Tools can be found at ${RVCT40_BIN}" )
Does it work if you replace the all the $ENV{}s with hardcoded paths ?
Please try that and let me know if it works then, so we can figure out a
solution.
Alex
>>>
Hi Alex,
replacing doesn´t work.
I also did some further investigation and it led me to a different problem,
that may be the reason for all this.
I think that the TRY_COMPILE macro of Cmake does not respect the
CMAKE_EXECUTABLE_SUFFIX that I have set to ".out".
So the TRY_COMPILE does not find the correctly built output file and further
processing fails.
Here´s the output of CMAKE:
-- Check for working CXX compiler:
C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe
-- Check for working CXX compiler:
C:/Programme/ARM/RVCT/Programs/4.0/436/multi1/win_32-pentium/armcc.exe -- works
-- Detecting CXX compiler ABI info
CMake Error: Could not COPY_FILE.
OutputFile: ''
copyFile: 'D:/proj/build/test2/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin'
Unable to find executable for try_compile: tried
"D:/proj/build/test2/CMakeFiles/CMakeTmp/cmTryCompileExec" and "D:/proj/build
/test2/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec" and
"D:/proj/build/test2/CMakeFiles/CMakeTmp/Development/cmTryCompileExec".
-- Suffix is:
-- Output is:
As you can see, I manually added the last to MESSAGEs to the
CmakeDetermineCompilerAbi.cmake that was shipped with Cmake 2.8.3.
When I add the line
SET( CMAKE_EXECUTABLE_SUFFIX .out )
In that file, the ABI check seems to work. So the big question is how to make
Cmake use the CMAKE_EXECUTABLE_SUFFIX that was given in the toolchain file?
Regards,
Alex
___
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 compiler and ABI check don´t work
On Friday 18 February 2011, Schmid Alexander wrote:
> Hi,
>
> of course, I´d like to have you think further about it, so here you go...
;-)
> This is the toolchain file I use.
> The specialty about is that I want to use the ARMCC as compiler and an
> SDK-provided linker tool for linking.
>
> # this one is important
> SET( CMAKE_SYSTEM_NAME Generic )
> # this one not so much
> SET( CMAKE_SYSTEM_VERSION 1 )
>
> #
> ---
>-- # setup local variables used
> #
> ---
>--
>
> SET( SDK1_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk1" )
> message( STATUS "The SDK1 can be found at ${SDK1_ROOT}" )
> SET( SDK1_INCLUDE "${SDK1_ROOT}/include" )
> STRING( REPLACE "\\" "/" SDK1_INCLUDE ${SDK1_INCLUDE} )
> SET( SDK1_LIB "${SDK1_ROOT}/lib" )
> STRING( REPLACE "\\" "/" SDK1_LIB ${SDK1_LIB} )
>
> SET( SDK2_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk2" )
> message( STATUS "The SDK2 can be found at ${SDK2_ROOT}" )
> SET( SDK2_INCLUDE "${SDK2_ROOT}/include" )
> STRING( REPLACE "\\" "/" SDK2_INCLUDE ${SDK2_INCLUDE} )
> SET( SDK2_LIB "${SDK2_ROOT}/lib" )
> STRING( REPLACE "\\" "/" SDK2_LIB ${SDK2_LIB} )
>
> SET( RVCT40_BIN "$ENV{RVCT40BIN}" )
> message( STATUS "The ARM Tools can be found at ${RVCT40_BIN}" )
Does it work if you replace the all the $ENV{}s with hardcoded paths ?
Please try that and let me know if it works then, so we can figure out a
solution.
Alex
___
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 compiler and ABI check don´t work
Hi,
of course, I´d like to have you think further about it, so here you go...
This is the toolchain file I use.
The specialty about is that I want to use the ARMCC as compiler and an
SDK-provided linker tool for linking.
# this one is important
SET( CMAKE_SYSTEM_NAME Generic )
# this one not so much
SET( CMAKE_SYSTEM_VERSION 1 )
#
-
# setup local variables used
#
-
SET( SDK1_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk1" )
message( STATUS "The SDK1 can be found at ${SDK1_ROOT}" )
SET( SDK1_INCLUDE "${SDK1_ROOT}/include" )
STRING( REPLACE "\\" "/" SDK1_INCLUDE ${SDK1_INCLUDE} )
SET( SDK1_LIB "${SDK1_ROOT}/lib" )
STRING( REPLACE "\\" "/" SDK1_LIB ${SDK1_LIB} )
SET( SDK2_ROOT "$ENV{PROJ_ROOT}\\tools\\Sdk2" )
message( STATUS "The SDK2 can be found at ${SDK2_ROOT}" )
SET( SDK2_INCLUDE "${SDK2_ROOT}/include" )
STRING( REPLACE "\\" "/" SDK2_INCLUDE ${SDK2_INCLUDE} )
SET( SDK2_LIB "${SDK2_ROOT}/lib" )
STRING( REPLACE "\\" "/" SDK2_LIB ${SDK2_LIB} )
SET( RVCT40_BIN "$ENV{RVCT40BIN}" )
message( STATUS "The ARM Tools can be found at ${RVCT40_BIN}" )
#
-
# setup object file extensions - must be forced to .o for being able to work
with compiler
#
-
SET( CMAKE_C_OUTPUT_EXTENSION .o )
SET( CMAKE_CXX_OUTPUT_EXTENSION .o )
SET( CMAKE_EXECUTABLE_SUFFIX .out )
# search for programs in the build host directories
SET( CMAKE_FIND_ROOT_PATH $SDK1_ROOT )
SET( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER )
# for libraries and headers in the target directories
SET( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
SET( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
#
-
# setup compiler and linker flags
#
-
SET( ARMCC_SPECIAL_FLAGS "-Ono_memcpy --library_interface=aeabi_clib
--no_unaligned_access -Ono_tree_sequencing --thumb -c --cpu ARM1136J-S --bi
-J\"${SDK1_INCLUDE}\" " )
# sets the --cpu ARM1136J-S switch on the ARMCC
SET( SDK1_LINKER_FLAGS "-p" )
IF( COMPILER_ADD_DEBUGGING_SYMBOLS )
SET( SDK1_LINKER_FLAGS "${SDK1_LINKER_FLAGS} -g -map" )
SET( CC_FLAGS "${CC_FLAGS} -g" )
ELSE( COMPILER_ADD_DEBUGGING_SYMBOLS )
SET( CC_FLAGS "${CC_FLAGS} -DNDEBUG" )
SET( SDK1_LINKER_FLAGS "${SDK1_LINKER_FLAGS} -DNDEBUG")
ENDIF( COMPILER_ADD_DEBUGGING_SYMBOLS )
IF( COMPILER_OPTIMIZE_FOR_SIZE )
SET ( CC_FLAGS "${CC_FLAGS} -Ospace" )
SET ( SDK1_LINKER_FLAGS "${SDK1_LINKER_FLAGS} -armcc,-Ospace" )
ENDIF( COMPILER_OPTIMIZE_FOR_SIZE )
IF( COMPILER_OPTIMIZE_FOR_SPEED )
SET ( CC_FLAGS "${CC_FLAGS} -O3,-Otime" )
SET ( SDK1_LINKER_FLAGS "${SDK1_LINKER_FLAGS} -armcc,-O3,-Otime" )
ENDIF( COMPILER_OPTIMIZE_FOR_SPEED )
#
-
# setup compilers and flags
#
-
# Compiler must have forward slashes in its path
STRING( REPLACE "\\" "/" ARMCC_ROOT ${RVCT40_BIN} )
SET( CMAKE_C_COMPILER "${ARMCC_ROOT}/armcc.exe" )
SET( CMAKE_CXX_COMPILER "${ARMCC_ROOT}/armcc.exe" )
# Linker must have escaped back slashes in its path
SET( SDK1_LINKER "${SDK1_ROOT}\\bin\\sdk1linker.exe" )
# specify the compile command
SET( CMAKE_C_FLAGS "${CC_FLAGS} -DLOGSYS_FLAG -DLOGSYS_NEW_API_STYLE
-I\"${SDK2_INCLUDE}\" " )
# The warning 830 is suppressed, because the arm compiler complains that there
is no corresponding "delete" for the "new( size_t, void*)".
# This is true on one hand, but on the other the standard defines the API for
new and delete just as it is implemented in the header.
# See e.g. http://www.cplusplus.com/reference/std/new/operator%20new/ and
http://www.cplusplus.com/reference/std/new/operator%20delete/
SET( CMAKE_CXX_FLAGS "${CC_FLAGS} -D__STDC_LIMIT_MACROS -DLOGSYS_FLAG
-DLOGSYS_NEW_API_STYLE --diag_suppress=1300,830 --cpp --exceptions
-I\"${SDK2_INCLUDE}\" " )
# This here is needed to manage to get the ARMCC and the SDK Linker (which
wraps armcc) working for the CMAKe startup tests.
# The next two lines set the "low-level" compiler call to accept all those
flags defined as CXX_INTERNAL_FLAGS. This means that
# each file will be compiled using these flags"
SET( CMAKE_CXX_COMPILE_OBJECT " ${ARMCC_SPECIAL_FLAGS}
-o -c ")
SET( CMAKE_C_COMPILE_OBJECT " ${ARMCC_SPECIAL_FLAGS}
-o -c ")
# specify the linker and its options for creating static libraries:
SET( CMAKE_AR_FLAGS "${SDK1_LINKER_FLAGS} -o ")
SET( CMAKE_CXX_CREATE_STATIC_LIBRARY "${SDK1_LINKER} ${CMAKE_AR_FLAGS}")
SET( CMAKE_C_CREATE_STATIC_LIBRARY "${SDK1_LINKER} ${CMAKE_AR_FLAGS}")
# specify the linker for
Re: [CMake] Cross-compiling: Cmake compiler and ABI check don´t work
On Thursday 17 February 2011, Schmid Alexander wrote: > Hi, > > is it possible that the ABI check won´t work anyway for cross-compiling > scenarios? It should. > Anyway, I don´t think that the toolchain file is messed up, because the > first part of CMake´s detection flow uses the settings I specified there. > But the second part doesn´t. I won't think further about it without seeing the file. If there are secrets in it, please replace them with "SecretStuff" or something. Alex ___ 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 compiler and ABI check don´t work
Hi, is it possible that the ABI check won´t work anyway for cross-compiling scenarios? Anyway, I don´t think that the toolchain file is messed up, because the first part of CMake´s detection flow uses the settings I specified there. But the second part doesn´t. Beste Grüße / Best regards Alexander Schmid Software Development CCV Deutschland GmbHFon: +49 (8752) 864 0 Gewerbering 1 Fax: +49 (8752) 864 100 84072 Au i.d. Hallertau www.ccv-deutschland.de www.ccv.eu a.sch...@de.ccv.eu HRB 177321 - Registergericht München Geschäftsführung: Reinhard Blum (Vorsitzender) Günther Froschermeier -Ursprüngliche Nachricht- Von: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Gesendet: Dienstag, 15. Februar 2011 22:49 An: cmake@cmake.org Cc: Schmid Alexander Betreff: Re: [CMake] Cross-compiling: Cmake compiler and ABI check don´t work Hi, On Friday 11 February 2011, Schmid Alexander wrote: > Hi, > > > > I am working with CMake 2.8.3 and trying to set up a cross-compiling > toolchain for an ARMCC that runs on a Windows system. > > > > What I´ve done up to now is that I set up a toolchain file that I am using > in combination with nmake makefiles. Can you please post the complete toolchain file ? Maybe there's something unusual in it. Alex ___ 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 compiler and ABI check don´t work
Hi, On Friday 11 February 2011, Schmid Alexander wrote: > Hi, > > > > I am working with CMake 2.8.3 and trying to set up a cross-compiling > toolchain for an ARMCC that runs on a Windows system. > > > > What I´ve done up to now is that I set up a toolchain file that I am using > in combination with nmake makefiles. Can you please post the complete toolchain file ? Maybe there's something unusual in it. Alex ___ 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 compiler and ABI check don´t work
> > On Friday 11 February 2011, Schmid Alexander wrote:
> > Hi,
> >
> >
> >
> > I am working with CMake 2.8.3 and trying to set up a cross-compiling
> > toolchain for an ARMCC that runs on a Windows system.
> >
> >
> >
> > What I´ve done up to now is that I set up a toolchain file that I am using
> > in combination with nmake makefiles.
> >
> > This file defines:
> >
> >
> >
> > SET( CMAKE_C_COMPILER "${ARMCC_ROOT}/armcc.exe" )
> >
> > SET( CMAKE_CXX_COMPILER "${ARMCC_ROOT}/armcc.exe" )
>
> Do you set CMAKE_SYSTEM_NAME ?
> If no, that's probably the problem.
> If yes, to what ? I guess Linux ?
>
> Alex
Hi,
the CMAKE_SYSTEM_NAME is set to "Generic".
___
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 compiler and ABI check don´t work
On Friday 11 February 2011, Schmid Alexander wrote:
> Hi,
>
>
>
> I am working with CMake 2.8.3 and trying to set up a cross-compiling
> toolchain for an ARMCC that runs on a Windows system.
>
>
>
> What I´ve done up to now is that I set up a toolchain file that I am using
> in combination with nmake makefiles.
>
> This file defines:
>
>
>
> SET( CMAKE_C_COMPILER "${ARMCC_ROOT}/armcc.exe" )
>
> SET( CMAKE_CXX_COMPILER "${ARMCC_ROOT}/armcc.exe" )
Do you set CMAKE_SYSTEM_NAME ?
If no, that's probably the problem.
If yes, to what ? I guess Linux ?
Alex
___
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 a static library (CMake 2.8.3)
On Monday 07 February 2011, Emmanuel Blot wrote: > >> FWIW: I found why I use CMAKE_FORCE_C_COMPILER rather than the simpler > >> CMAKE_C_COMPILER command: > >> I build projects for eCos from outside the eCos tree directory, and > >> CMake has some trouble finding the eCos header files when simply using > >> CMAKE_C_COMPILER. It complains about CMAKE_FIND_ROOT_PATH which is > >> nevertheless defined as expected. > > Sorry to get back so late on this topic > > > You should not need to use CMAKE_FORCE_C_COMPILER() for eCos. > > Can you please post some more details on your setup ? > > I build eCos-based projects for ARM. The compiler prefix is "arm-eabi-" > > The basic directory layout is as follows: > > ecos/ : contains the std eCos "packages" subdir, etc. > sdk/ : contains our base code, that builds against eCos > > build/ : where all the code is built (out-of-source build), that is: > build/ecos_build > build/ecos_install > build/sdk ... > > > Where is the eCos tree with libtarget.a etc. ? > > build/ecos_install/lib/libtarget.a > build/ecos_install/include/pkgconf/system.h > > > How does your toolchain file look like ? > > arm-eabi-gcc-4.5.2 (on Linux, Mac OS X), arm-eabi-gcc-4.5.2.exe (on Cygwin) > all other toolchain tools are prefixed with arm-eabi- as well > > > How do you call cmake ? > > From a shell script. A simplified version of the command line would be > (TOPDIR does not exist, TOPDIR is actually the absolute path to the > startup directory) > > TOPDIR=$PWD > (cd build/sdk && > cmake -DCMAKE_FIND_ROOT_PATH=$TOPDIR/build/ecos_install \ >-DSDK_PATH=$TOPDIR/build/sdk/install -DCMAKE_BUILD_TYPE=DEBUG \ >-DPYTHON=/usr/bin/python2.6 ../../sdk && /usr/bin/make install) Where do you set the toolchain file ? I would have expected it in the command line. > I also define: > > SET (CMAKE_SYSTEM_NAME eCos) > SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY LAST) > SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE LAST) > > (again, I can't remember why I selected "LAST" at some point in the > past, but "ONLY" led to some other issues) > > When I drop CMAKE_FORCE_C_COMPILER and replace it with > CMAKE_C_COMPILER, I get the following error message > > Building sdk in DEBUG > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /usr/local/homebrew/bin/arm-eabi-gcc-4.5.2 > CMake Error at > /usr/local/homebrew/Cellar/cmake/2.8.4-rc2/share/cmake/Modules/Platform/eCo >s.cmake:36 (MESSAGE): > Could not find eCos pkgconf/system.h. Build eCos first and set up > CMAKE_FIND_ROOT_PATH correctly. Ok, found it. CMAKE_FIND_ROOT_PATH must be set in the toolchain file. The error comes from within a try_compile() call. For this, a tiny new cmake project is created. There, the toolchain file is included, so stuff set in the toolchain file works there too. Now you set CMAKE_FIND_ROOT_PATH via -D, so it is not known to the test project created by try_compile(), so the find_path() fails. In which directory is the toolchain file located ? Is it in TOPDIR/ ? Alex ___ 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 a static library (CMake 2.8.3)
>> FWIW: I found why I use CMAKE_FORCE_C_COMPILER rather than the simpler >> CMAKE_C_COMPILER command: >> I build projects for eCos from outside the eCos tree directory, and >> CMake has some trouble finding the eCos header files when simply using >> CMAKE_C_COMPILER. It complains about CMAKE_FIND_ROOT_PATH which is >> nevertheless defined as expected. Sorry to get back so late on this topic > You should not need to use CMAKE_FORCE_C_COMPILER() for eCos. > Can you please post some more details on your setup ? I build eCos-based projects for ARM. The compiler prefix is "arm-eabi-" The basic directory layout is as follows: ecos/ : contains the std eCos "packages" subdir, etc. sdk/ : contains our base code, that builds against eCos build/ : where all the code is built (out-of-source build), that is: build/ecos_build build/ecos_install build/sdk ... > Where is the eCos tree with libtarget.a etc. ? build/ecos_install/lib/libtarget.a build/ecos_install/include/pkgconf/system.h > How does your toolchain file look like ? arm-eabi-gcc-4.5.2 (on Linux, Mac OS X), arm-eabi-gcc-4.5.2.exe (on Cygwin) all other toolchain tools are prefixed with arm-eabi- as well > How do you call cmake ? >From a shell script. A simplified version of the command line would be (TOPDIR does not exist, TOPDIR is actually the absolute path to the startup directory) TOPDIR=$PWD (cd build/sdk && cmake -DCMAKE_FIND_ROOT_PATH=$TOPDIR/build/ecos_install \ -DSDK_PATH=$TOPDIR/build/sdk/install -DCMAKE_BUILD_TYPE=DEBUG \ -DPYTHON=/usr/bin/python2.6 ../../sdk && /usr/bin/make install) I also define: SET (CMAKE_SYSTEM_NAME eCos) SET (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) SET (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY LAST) SET (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE LAST) (again, I can't remember why I selected "LAST" at some point in the past, but "ONLY" led to some other issues) When I drop CMAKE_FORCE_C_COMPILER and replace it with CMAKE_C_COMPILER, I get the following error message Building sdk in DEBUG -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/local/homebrew/bin/arm-eabi-gcc-4.5.2 CMake Error at /usr/local/homebrew/Cellar/cmake/2.8.4-rc2/share/cmake/Modules/Platform/eCos.cmake:36 (MESSAGE): Could not find eCos pkgconf/system.h. Build eCos first and set up CMAKE_FIND_ROOT_PATH correctly. Call Stack (most recent call first): /usr/local/homebrew/Cellar/cmake/2.8.4-rc2/share/cmake/Modules/CMakeSystemSpecificInformation.cmake:36 (INCLUDE) CMakeLists.txt:2 (PROJECT) Best Regards, Emmanuel ___ 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
Hi Justin,
On Tuesday 14 December 2010, Justin Holewinski wrote:
> On Tue, Dec 14, 2010 at 4:45 AM, Johan Björk 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.
please put your problem in the cmake bug tracker
http://public.kitware.com/Bug/ and assign it to me.
Thanks
Alex
___
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 a static library (CMake 2.8.3)
On Monday 10 January 2011, Emmanuel Blot wrote: > >> INCLUDE (CMakeForceCompiler) > >> CMAKE_FORCE_C_COMPILER (arm-eabi-gcc-4.5.2 GNU 4) > > > > I haven't used that one before. > > FWIW: I found why I use CMAKE_FORCE_C_COMPILER rather than the simpler > CMAKE_C_COMPILER command: > I build projects for eCos from outside the eCos tree directory, and > CMake has some trouble finding the eCos header files when simply using > CMAKE_C_COMPILER. It complains about CMAKE_FIND_ROOT_PATH which is > nevertheless defined as expected. You should not need to use CMAKE_FORCE_C_COMPILER() for eCos. Can you please post some more details on your setup ? Where is the eCos tree with libtarget.a etc. ? How does your toolchain file look like ? How do you call cmake ? Do the instructions from that wiki page http://cmake.org/Wiki/CmakeEcos work for you if you use the described setup ? Do they only fail if you use a different setup ? Alex ___ 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 a static library (CMake 2.8.3)
>> INCLUDE (CMakeForceCompiler) >> CMAKE_FORCE_C_COMPILER (arm-eabi-gcc-4.5.2 GNU 4) > > I haven't used that one before. FWIW: I found why I use CMAKE_FORCE_C_COMPILER rather than the simpler CMAKE_C_COMPILER command: I build projects for eCos from outside the eCos tree directory, and CMake has some trouble finding the eCos header files when simply using CMAKE_C_COMPILER. It complains about CMAKE_FIND_ROOT_PATH which is nevertheless defined as expected. Cheers, Manu ___ 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 a static library (CMake 2.8.3)
> The docs say that the signature is
> CMAKE_FORCE_C_COMPILER( )
> so maybe something bad happens when you give it that extra
> argument "4"? Try without "4"?
Actually, it changes nothing.
*but* if I remove the specific version number for the compiler, i.e. I define
FIND_PROGRAM (xcc ${XTOOLCHAIN}-gcc)
instead of
FIND_PROGRAM (xcc ${XTOOLCHAIN}-gcc-${XCC_VER})
then the proper ranlib tool is called.
In other words (I double-check with MESSAGE (STATUS "PREFIX:
${_CMAKE_TOOLCHAIN_PREFIX}")), if no GCC version is specified, the
toolchain prefix is detected, however if a specific compiler version
is specified, the toolchain prefix is empty.
There's may be a limitation with the syntax matching rule here. Should
I log a bug ?
Cheers,
Manu
___
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 a static library (CMake 2.8.3)
Hi, (CCing the list.) 2011/1/10 Emmanuel Blot : >> When I cross compile I do "set(CMAKE_C_COMPILER arm-linux-gcc)" >> in a toolchain file and CMake automatically finds ranlib (and other >> toolchain utilities) using the prefix from the C compiler. How do you >> setup CMake for cross-compilation? > > INCLUDE (CMakeForceCompiler) > CMAKE_FORCE_C_COMPILER (arm-eabi-gcc-4.5.2 GNU 4) I haven't used that one before. The docs say it should be used when CMake is not able to detect the compiler ID. Is that the case here? Have you tried "set(CMAKE_C_COMPILER arm-linux-gcc)"? > Maybe the version number is the source of the trouble ? The docs say that the signature is CMAKE_FORCE_C_COMPILER( ) so maybe something bad happens when you give it that extra argument "4"? Try without "4"? Best regards, Bjørn Forsman >> Have you read http://cmake.org/Wiki/CMake_Cross_Compiling ? > Not for a while, however I've been using CMake for cross compiling > since early releases (2.5.x), so maybe the syntax changed a bit since. ___ 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 a static library (CMake 2.8.3)
Hi, On 10 January 2011 17:00, Emmanuel Blot wrote: > Hello, > > Using the ADD_LIBRARY command for a static library (.a), how to tell > CMake to use the ranlib tool for the target, not the default one for > the host? > > I'm getting the following warning message: > > cd watchdog && /usr/local/Cellar/cmake/2.8.3/bin/cmake -E > cmake_link_script CMakeFiles/nd_watchdog.dir/link.txt --verbose=1 > /usr/bin/ar cr libnd_watchdog.a > CMakeFiles/nd_watchdog.dir/src/nd_watchdog.c.o > /usr/bin/ranlib libnd_watchdog.a > /usr/bin/ranlib: warning for library: libnd_watchdog.a the table of > contents is empty (no object file members in the library define global > symbols) > > I'd like to use our dedicated arm-eabi-ranlib tool instead. When I cross compile I do "set(CMAKE_C_COMPILER arm-linux-gcc)" in a toolchain file and CMake automatically finds ranlib (and other toolchain utilities) using the prefix from the C compiler. How do you setup CMake for cross-compilation? Have you read http://cmake.org/Wiki/CMake_Cross_Compiling ? Best regards, Bjørn Forsman ___ 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 a static library (CMake 2.8.3)
> I'm getting the following warning message: >From http://www.cmake.org/pipermail/cmake/2010-September/039705.html, it seems on my development environment that _CMAKE_TOOLCHAIN_PREFIX is left empty. If I force this variable to the expected value (arm-eabi-), the proper tools are detected and invoked as expected. However, _CMAKE_TOOLCHAIN_PREFIX is an CMake internal variable. Is there a better way to define it? Cheers, Manu ___ 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 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
>>
>>
Re: [CMake] Cross-compiling, CMAKE_C_FLAGS, and configure-time compiler tests
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)
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
>
> /opt/local/bin/cmake -E cmake_progress_report
>
>
> /Users/jholewinski/projects/rapture/build-test/ios/CMakeFiles/CMakeTmp/CMakeFiles
> 1
>
> Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj
>
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2
>
>
> -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/include
> -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.obj -c
>
>
> /Users/jholewinski/projects/rapture/build-test/ios/CMakeFiles/CMakeTmp/testCCompiler.c
>
>
> Linking C executable cmTryCompileExec
>
> /opt/local/bin/cmak
Re: [CMake] cross compiling - platform files
On Friday 02 July 2010, Kishore wrote:
> On Thursday 01 Jul 2010 8:13:56 pm Kishore wrote:
> > In the CMake wiki (http://www.cmake.org/Wiki/CMake_Cross_Compiling) it
> > says clearly that the platform module are included in the following
> > order;
> >
> > Platform/${CMAKE_SYSTEM_NAME}.cmake (mandatory)
> > Platform/${CMAKE_SYSTEM_NAME}-.cmake (optional)
> > Platform/${CMAKE_SYSTEM_NAME}--${CMAKE_SYSTEM_PROCESSOR}.cmake
> > (optional)
> >
> > However, in my project it seems that They are included in the reverse
> > order to that. At least, Generic-gcc-${CMAKE_SYSTEM_PROCESSOR}.cmake is
> > included before Generic-gcc.cmake.
> >
> > Can someone kindly confirm. Is this a bug in cmake or an error in
> > documentation?
>
> Anyone? What was the original intension when cresting this feature?
Wiki page seems to be wrong.
The CMAKE_SYSTEM_PROCESSOR file is included first so that there
hardware-specific flags can be set, which can then be inserted into the
compile or link variables in the more generic
${CMAKE_SYSTEM_NAME}-.cmake file.
This is usually necessary when working on embedded projects where different
compiler or linker flags are needed depending on the target hardware.
Alex
___
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: Add Support for IAR compiler
On Thursday 22 July 2010, Hassan Mansouri wrote: > Hi, > I am trying to do cross-compiling with CMake for IAR compiler (ARM). > My main problem with the current CMake 2.8.2 is the complain about -c > option from IAR compiler. IAR compiler does not accept -c as input C file > and the sysntax is CC .c [options]. How can I tell CMake not to > put -c when calling the external compiler when it's IAR? > > There is a link for supporting IAR compiler in CMake at: > http://www.cmake.org/Bug/view.php?id=10176 but I don't know how to apply > the changes. > Can anybody tell me what is the conclusion and how can I apply the required > patches to CMake? This discussion is for CMake 2.6, is this fixed in newer > version of CMake? I plan to finish the work on this in the next weeks, and I'm happy if you can help me with that. Let's continue the discussion in the bugtracker in the next days. Alex ___ 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 - platform files
On Thursday 01 Jul 2010 8:13:56 pm Kishore wrote:
> In the CMake wiki (http://www.cmake.org/Wiki/CMake_Cross_Compiling) it says
> clearly that the platform module are included in the following order;
>
> Platform/${CMAKE_SYSTEM_NAME}.cmake (mandatory)
> Platform/${CMAKE_SYSTEM_NAME}-.cmake (optional)
> Platform/${CMAKE_SYSTEM_NAME}--${CMAKE_SYSTEM_PROCESSOR}.cmake
> (optional)
>
> However, in my project it seems that They are included in the reverse order
> to that. At least, Generic-gcc-${CMAKE_SYSTEM_PROCESSOR}.cmake is included
> before Generic-gcc.cmake.
>
> Can someone kindly confirm. Is this a bug in cmake or an error in
> documentation?
Anyone? What was the original intension when cresting this feature?
--
Cheers!
Kishore
___
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 / host compiling
On Monday 07 June 2010, Aeschbacher, Fabrice wrote: > Thank you for responding > > Actually, I noticed that putting following line in the CMakeLists.txt of > the tool that should not be cross-compiled also works: > > SET(CMAKE_C_COMPILER "gcc") > > The only drawback I found until now is that the native compiler (gcc) is > not checked by cmake at startup (which is for us a minor issue) Yes, you can set all the required variables manually, but this is not recommended. E.g. the results of try_compile() checks (like check_c_source_compiles(), check_include_files() etc.) are cached globally, so they will have the value for the compiler which was active in that directory, there will not be separate results for the different compilers. Also cmake will not know that e.g. it can't link the libraries from these directories together etc. If you are aware of these issue, it should work. Alex ___ 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 / host compiling
Thank you for responding Actually, I noticed that putting following line in the CMakeLists.txt of the tool that should not be cross-compiled also works: SET(CMAKE_C_COMPILER "gcc") The only drawback I found until now is that the native compiler (gcc) is not checked by cmake at startup (which is for us a minor issue) Best regards, Fabrice Aeschbacher > -Ursprüngliche Nachricht- > Von: Michael Wild [mailto:them...@gmail.com] > Gesendet: Donnerstag, 3. Juni 2010 14:15 > An: Alexander Neundorf > Cc: cmake@cmake.org; Aeschbacher, Fabrice > Betreff: Re: [CMake] cross-compiling / host compiling > > > On 3. Jun, 2010, at 14:09 , Alexander Neundorf wrote: > > >> I have a project where almost every sub-dirs should be > cross-compiled > >> (arm-linux-gnuueabi-gcc), but one directory containing a > tool which must be > >> compiled on the host (gcc) first. > >> > >> Can you give me a hint about the best way to achieve this > with cmake? > > > > They need to be compiled separately. > > With cmake, one buildtree is always one toolchain, using > more than one > > toolchain in one buildtree is not supported. > > > > So you first need to build the tool in a native build tree, > and then build the > > rest in a cross compiling tree. > > You may want to "export" the tool from the native buildtree > and "import" it > > again in the cross compiling tree. > > > > Alex > > Or use an ExternalProject_Add for the native tool and then do > an ADD_EXECUTABLE(tool IMPORTED) in the cross compiling > top-level project. > > Michael ___ 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 / host compiling
On 3. Jun, 2010, at 14:09 , Alexander Neundorf wrote: > On Wednesday 02 June 2010, Aeschbacher, Fabrice wrote: >> [Sorry if this message is posted twice, but first was before I subscribed >> to the list, so I'm not sure it was not rejected] >> >> >> Hi, >> >> [using cmake 2.8.1] >> >> I have a project where almost every sub-dirs should be cross-compiled >> (arm-linux-gnuueabi-gcc), but one directory containing a tool which must be >> compiled on the host (gcc) first. >> >> Can you give me a hint about the best way to achieve this with cmake? > > They need to be compiled separately. > With cmake, one buildtree is always one toolchain, using more than one > toolchain in one buildtree is not supported. > > So you first need to build the tool in a native build tree, and then build > the > rest in a cross compiling tree. > You may want to "export" the tool from the native buildtree and "import" it > again in the cross compiling tree. > > Alex Or use an ExternalProject_Add for the native tool and then do an ADD_EXECUTABLE(tool IMPORTED) in the cross compiling top-level project. Michael ___ 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 / host compiling
On Wednesday 02 June 2010, Aeschbacher, Fabrice wrote: > [Sorry if this message is posted twice, but first was before I subscribed > to the list, so I'm not sure it was not rejected] > > > Hi, > > [using cmake 2.8.1] > > I have a project where almost every sub-dirs should be cross-compiled > (arm-linux-gnuueabi-gcc), but one directory containing a tool which must be > compiled on the host (gcc) first. > > Can you give me a hint about the best way to achieve this with cmake? They need to be compiled separately. With cmake, one buildtree is always one toolchain, using more than one toolchain in one buildtree is not supported. So you first need to build the tool in a native build tree, and then build the rest in a cross compiling tree. You may want to "export" the tool from the native buildtree and "import" it again in the cross compiling tree. Alex ___ 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
On 5. Jan, 2010, at 19:55 , Alexander Neundorf wrote: > On Tuesday 05 January 2010, Michael Wild wrote: >> On 4. Jan, 2010, at 19:15 , Alexander Neundorf wrote: >> [snip] >> - There is no distinction between install prefixes for the target and the host. Sometimes I'd like to put various build tools on the host system at the same time as libs and binaries on the target root. >>> >>> In CMake one build tree uses one toolchain. So in one build tree you can >>> only create executable which run either for the target, of for the host, >>> not both in one go. >>> So if you need first to create host build tools, and later on use them >>> for the actual cross compile, you need two build trees. I would recommend >>> to "export" the executable and "import" them again in the cross build. >>> >>> If this is not your problem, but really just the install location, you >>> can set the install location of every install() command separately, this >>> is completely independent from the cross compiling support. >> >> To automate this you can use the ExternalProject.cmake that comes with >> CMake-2.8 to build the host tools. > > Maybe, I haven't tried to combine this yet. > >> You can then use add_executable(tool >> IMPORTED) and set_target_properties(tool PROPERTIES IMPORTED_LOCATION ...) >> to import the tool target into the cross-compiling project. > > That's not necessary to do manually. You can use the EXPORT feature for the > necessary executables, something like this: > If you don't want to install the project first, you can add an > if(NOT CMAKE_CROSSCOMPILING) > export(TARGETS ... ) > endif(NOT CMAKE_CROSSCOMPILING) > to create such a export file in the buildtree. > > Alex > I thought of that too, but then you have to run CMake a second time after the first build failed because the export file won't be created until build-time. Chicken-egg thing again :-( Michael ___ 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
On Tuesday 05 January 2010, Michael Wild wrote: > On 4. Jan, 2010, at 19:15 , Alexander Neundorf wrote: > [snip] > > >> - There is no distinction between install prefixes for the target and > >> the host. Sometimes I'd like to put various build tools on the host > >> system at the same time as libs and binaries on the target root. > > > > In CMake one build tree uses one toolchain. So in one build tree you can > > only create executable which run either for the target, of for the host, > > not both in one go. > > So if you need first to create host build tools, and later on use them > > for the actual cross compile, you need two build trees. I would recommend > > to "export" the executable and "import" them again in the cross build. > > > > If this is not your problem, but really just the install location, you > > can set the install location of every install() command separately, this > > is completely independent from the cross compiling support. > > To automate this you can use the ExternalProject.cmake that comes with > CMake-2.8 to build the host tools. Maybe, I haven't tried to combine this yet. > You can then use add_executable(tool > IMPORTED) and set_target_properties(tool PROPERTIES IMPORTED_LOCATION ...) > to import the tool target into the cross-compiling project. That's not necessary to do manually. You can use the EXPORT feature for the necessary executables, something like this: If you don't want to install the project first, you can add an if(NOT CMAKE_CROSSCOMPILING) export(TARGETS ... ) endif(NOT CMAKE_CROSSCOMPILING) to create such a export file in the buildtree. Alex ___ 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
On 4. Jan, 2010, at 19:15 , Alexander Neundorf wrote: [snip] > >> - There is no distinction between install prefixes for the target and the >> host. Sometimes I'd like to put various build tools on the host system at >> the same time as libs and binaries on the target root. > > In CMake one build tree uses one toolchain. So in one build tree you can only > create executable which run either for the target, of for the host, not both > in one go. > So if you need first to create host build tools, and later on use them for > the > actual cross compile, you need two build trees. I would recommend to "export" > the executable and "import" them again in the cross build. > > If this is not your problem, but really just the install location, you can > set > the install location of every install() command separately, this is > completely independent from the cross compiling support. To automate this you can use the ExternalProject.cmake that comes with CMake-2.8 to build the host tools. You can then use add_executable(tool IMPORTED) and set_target_properties(tool PROPERTIES IMPORTED_LOCATION ...) to import the tool target into the cross-compiling project. Michael ___ 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
We're happily cross-compiling for System z (z/OS on IBM mainframe) using the
Dignus cross-compiler under Windows. This is extra fun because it's a two-stage
compiler (C/C++ to assembler, assembler to object). It's all working fine; the
hard parts were:
- creating the .cmake files needed (they aren't complicated, but weren't
obvious, and we have to remember to re-add them for each new install or upgrade
of CMake and to copy the toolchain file to each build directory)
- creating the script that gets invoked to do the compiles (it does both stages)
- getting the right version of make (Cygwin)
- getting the environment variables right
We created a bunch of tooling that lets us use a single command to do the
CMake, CMake+make, or just the make, as well as to package the files for
transfer to z/OS (you *really* don't want to know how painful that part is,
trust me).
My dad always said "an example is worth 1000 pages of doc", so while I doubt
this will be very useful to you, here are our files. Alexander was instrumental
in getting us going with this -- so anything he says that contradicts me is
probably correct!
Our toolchain file (in the build directory):
# This is a CMake Toolchain file, required for cross-compiling using
# the Dignus cross-compilers on Windows, compiling for z/OS.
# Tell CMAKE the target system name
SET(CMAKE_SYSTEM_NAME "IBM_ZOS")
# Specify the cross-compilers
SET(CMAKE_C_COMPILER "rexx.exe" "cc.rex dcc.exe")
SET(CMAKE_CXX_COMPILER "rexx.exe" "cc.rex dcxx.exe")
SET(CMAKE_C_CREATE_STATIC_LIBRARY "DAR -rv ")
SET(CMAKE_CXX_LINK_EXECUTABLE "plink.exe
\"-S$ENV{DIGNUS_PROGRAM}/objs_norent/&M\" -o ")
SET(CMAKE_C_LINK_EXECUTABLE "plink.exe
\"-S$ENV{DIGNUS_PROGRAM}/objs_norent/&M\" -o ")
Our CMakeASM_DIGNUSInformation.cmake (in CMake 2.8\share\cmake-2.8\Modules or
equivalent):
set(ASM_DIALECT _DIGNUS)
include(CMakeASMInformation)
set(ASM_DIALECT)
SET(CMAKE_ASM_DIGNUS_SOURCE_FILE_EXTENSIONS assemble;asm)
SET(CMAKE_ASM_DIGNUS_OUTPUT_EXTENSION ".o" )
SET(CMAKE_ASM_DIGNUS_COMPILE_OBJECT " -o
")
Our CMakeTestASM_DIGNUSCompiler.cmake (in CMake 2.8\share\cmake-2.8\Modules or
equivalent)::
set(ASM_DIALECT _DIGNUS)
include(CMakeTestASMCompiler)
set(ASM_DIALECT)
Our CMakeDetermineASM_DIGNUSCompiler.cmake (in CMake
2.8\share\cmake-2.8\Modules or equivalent)::
SET(ASM_DIALECT _DIGNUS)
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_INIT "asmit.bat")
INCLUDE(CMakeDetermineASMCompiler)
SET(ASM_DIALECT)
Our IBM_ZOS.cmake (in the Platform\ directory under the above):
INCLUDE(Platform/UnixPaths)
HTH. Or at least doesn't hurt.
...phsiii
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Alexander Neundorf
Sent: Monday, January 04, 2010 1:16 PM
To: cmake@cmake.org
Subject: Re: [CMake] Cross Compiling
Hi,
On Monday 04 January 2010, Daniel Stonier wrote:
> The more I use cmake, the more I find it difficult to bend in to shape to
> cross compile. The original design doesn't seem to be designed for anything
> more than windows-linux or linux-windows cross compiles.
No. It is tested for
* x86 Linux to ARM/MIPS/PPC Linux
* x86 Linux to x86 Windows
* x86 Windows to x86 Linux
(not sure I tested also x86 Windows to ARM/MIPS/PPC Linux)
* x86 Linux to 16bit uC without OS
* x86 Linux to ARM/PPC eCos
* x86 Linux to PPC CNK
> Some things I'm having to currently work around by creating my own
> cross-compiling set of modules. My host is an amd64 linux and my target is
> an arm linux.
>
> - You can't set CMAKE_SYSTEM_NAME to anything useful other than Linux,
> which of course doesn't trigger the cross-compile variable CROSS_COMPILING
> because the host is the same.
See my other mail. You need to preset CMAKE_SYSTEM_NAME.
> - There is no distinction between install prefixes for the target and the
> host. Sometimes I'd like to put various build tools on the host system at
> the same time as libs and binaries on the target root.
In CMake one build tree uses one toolchain. So in one build tree you can only
create executable which run either for the target, of for the host, not both
in one go.
So if you need first to create host build tools, and later on use them for the
actual cross compile, you need two build trees. I would recommend to "export"
the executable and "import" them again in the cross build.
If this is not your problem, but really just the install location, you can set
the install location of every install() command separately, this is
completely independent from the cross compiling support.
> - Debian packaging in cpack will only ever put things in /usr, regardless
&g
Re: [CMake] Cross Compiling
Hi, On Monday 04 January 2010, Daniel Stonier wrote: > The more I use cmake, the more I find it difficult to bend in to shape to > cross compile. The original design doesn't seem to be designed for anything > more than windows-linux or linux-windows cross compiles. No. It is tested for * x86 Linux to ARM/MIPS/PPC Linux * x86 Linux to x86 Windows * x86 Windows to x86 Linux (not sure I tested also x86 Windows to ARM/MIPS/PPC Linux) * x86 Linux to 16bit uC without OS * x86 Linux to ARM/PPC eCos * x86 Linux to PPC CNK > Some things I'm having to currently work around by creating my own > cross-compiling set of modules. My host is an amd64 linux and my target is > an arm linux. > > - You can't set CMAKE_SYSTEM_NAME to anything useful other than Linux, > which of course doesn't trigger the cross-compile variable CROSS_COMPILING > because the host is the same. See my other mail. You need to preset CMAKE_SYSTEM_NAME. > - There is no distinction between install prefixes for the target and the > host. Sometimes I'd like to put various build tools on the host system at > the same time as libs and binaries on the target root. In CMake one build tree uses one toolchain. So in one build tree you can only create executable which run either for the target, of for the host, not both in one go. So if you need first to create host build tools, and later on use them for the actual cross compile, you need two build trees. I would recommend to "export" the executable and "import" them again in the cross build. If this is not your problem, but really just the install location, you can set the install location of every install() command separately, this is completely independent from the cross compiling support. > - Debian packaging in cpack will only ever put things in /usr, regardless > of cross-compiles or different CMAKE_INSTALL_PREFIX. Refer again to above > comment. What is the connection between Debian and cpack and the cross compiling ? Can you please explain ? > Having some useful autotools install style variables (--prefix and > --exec-prefix), someway of utilising of proper gnu tuples (e.g. > arm-unknown-linux-gnueabi) would make things alot easier. Can you please elaborate on this ? Alex ___ 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
On Monday 04 January 2010, Daniel Stonier wrote: > 2010/1/4 David Cole > > > Are you following the directions here? > > http://www.cmake.org/Wiki/CMake_Cross_Compiling > > > > Or trying to cross compile some other way...? > > > > > > Yes, that's where I got started - been using that for quite a while. Just > > noticed some loose ends recently. Note - if I follow that for something > like the eldk example (used to do exactly that for a powerpc board), > CROSS_COMPILING never gets set because both host and target system names > are Linux. the main point is not whether they are different, the main point is whether cmake detects the OS itself (then it detects what is running on the build host, and it is not cross compilint), or whether this is already preset (to keep cmake from detecting the OS itself, which mean that it is a cross compile, since this is the only condition where it doesn't make sense to have cmake detect it automatically). So even if the OS is the same for host and target, you still need to preset the CMAKE_SYSTEM_NAME variable. Alex ___ 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
2010/1/4 David Cole > Are you following the directions here? > http://www.cmake.org/Wiki/CMake_Cross_Compiling > > Or trying to cross compile some other way...? > > > Yes, that's where I got started - been using that for quite a while. Just noticed some loose ends recently. Note - if I follow that for something like the eldk example (used to do exactly that for a powerpc board), CROSS_COMPILING never gets set because both host and target system names are Linux. Doesn't stop you from compiling though. Also, I just noticed the cpack modules for deb packages got a bit of a facelift with 2.8.0 that might solve the problems there - will give them a whirl shortly. Thanks, Daniel. > On Mon, Jan 4, 2010 at 3:00 AM, Daniel Stonier wrote: > >> >> The more I use cmake, the more I find it difficult to bend in to shape to >> cross compile. The original design doesn't seem to be designed for anything >> more than windows-linux or linux-windows cross compiles. >> >> Some things I'm having to currently work around by creating my own >> cross-compiling set of modules. My host is an amd64 linux and my target is >> an arm linux. >> >> - You can't set CMAKE_SYSTEM_NAME to anything useful other than Linux, >> which of course doesn't trigger the cross-compile variable CROSS_COMPILING >> because the host is the same. >> - There is no distinction between install prefixes for the target and the >> host. Sometimes I'd like to put various build tools on the host system at >> the same time as libs and binaries on the target root. >> - Debian packaging in cpack will only ever put things in /usr, regardless >> of cross-compiles or different CMAKE_INSTALL_PREFIX. Refer again to above >> comment. >> >> Having some useful autotools install style variables (--prefix and >> --exec-prefix), someway of utilising of proper gnu tuples (e.g. >> arm-unknown-linux-gnueabi) would make things alot easier. >> >> Is this planned or is this something that could use a nudge to move into a >> useful direction? >> >> Do many other people cross-compile much with cmake? >> >> -- >> Phone : +82-10-5400-3296 (010-5400-3296) >> HomePage: http://snorriheim.dnsdojo.com/ >> Yujin Robot: http://www.yujinrobot.com/ >> Projects: http://snorriheim.dnsdojo.com/redmine/projects >> >> ___ >> 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 >> > > -- Phone : +82-10-5400-3296 (010-5400-3296) HomePage: http://snorriheim.dnsdojo.com/ Yujin Robot: http://www.yujinrobot.com/ Projects: http://snorriheim.dnsdojo.com/redmine/projects ___ 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
Are you following the directions here? http://www.cmake.org/Wiki/CMake_Cross_Compiling Or trying to cross compile some other way...? On Mon, Jan 4, 2010 at 3:00 AM, Daniel Stonier wrote: > > The more I use cmake, the more I find it difficult to bend in to shape to > cross compile. The original design doesn't seem to be designed for anything > more than windows-linux or linux-windows cross compiles. > > Some things I'm having to currently work around by creating my own > cross-compiling set of modules. My host is an amd64 linux and my target is > an arm linux. > > - You can't set CMAKE_SYSTEM_NAME to anything useful other than Linux, > which of course doesn't trigger the cross-compile variable CROSS_COMPILING > because the host is the same. > - There is no distinction between install prefixes for the target and the > host. Sometimes I'd like to put various build tools on the host system at > the same time as libs and binaries on the target root. > - Debian packaging in cpack will only ever put things in /usr, regardless > of cross-compiles or different CMAKE_INSTALL_PREFIX. Refer again to above > comment. > > Having some useful autotools install style variables (--prefix and > --exec-prefix), someway of utilising of proper gnu tuples (e.g. > arm-unknown-linux-gnueabi) would make things alot easier. > > Is this planned or is this something that could use a nudge to move into a > useful direction? > > Do many other people cross-compile much with cmake? > > -- > Phone : +82-10-5400-3296 (010-5400-3296) > HomePage: http://snorriheim.dnsdojo.com/ > Yujin Robot: http://www.yujinrobot.com/ > Projects: http://snorriheim.dnsdojo.com/redmine/projects > > ___ > 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 > ___ 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 on OS X/x86 for Linux/ARM, linking alibrary
Vladimir Lebedev-Schmidthof wrote: No I didn't. I just did and all compiled and linked successfully. Sorry for stupid questions then, I will remember to clean cmake-generated files in future. Thank you very much. -- You should use out of source builds in the future... :) -Bill ___ 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 on OS X/x86 for Linux/ARM, linking alibrary
Hello Hendrik, On Oct 20, 2009, at 17:50 PM, Hendrik Sattler wrote: Zitat von Vladimir Lebedev-Schmidthof : > I tried having toochain.cmake file in the same dir as CMakeLists.txt > > using > cmake -DCMAKE_TOOLCHAIN_FILE=./toolchain.cmake . > > does not seem to even read that file. I tried to state full path, move > the file away, no luck. Since you are doing an in-source build: did you make sure prior to issuing the above command that you cleaned the source directory from all cmake-generated files from previous runs (especially removing any CMakeCache.txt files)? No I didn't. I just did and all compiled and linked successfully. Sorry for stupid questions then, I will remember to clean cmake- generated files in future. Thank you very much. -- Sincerely Yours, Vladimir Lebedev-Schmidthof ___ 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 on OS X/x86 for Linux/ARM, linking a library
Zitat von Vladimir Lebedev-Schmidthof : I tried having toochain.cmake file in the same dir as CMakeLists.txt using cmake -DCMAKE_TOOLCHAIN_FILE=./toolchain.cmake . does not seem to even read that file. I tried to state full path, move the file away, no luck. Since you are doing an in-source build: did you make sure prior to issuing the above command that you cleaned the source directory from all cmake-generated files from previous runs (especially removing any CMakeCache.txt files)? HS ___ 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 on OS X/x86 for Linux/ARM, linking a library
Hello Hendrik, On Oct 20, 2009, at 15:56 PM, Hendrik Sattler wrote: > I tried. Setting CMAKE_SYSTEM_NAME to "Linux" does not seem to affect > CMAKE_SYSTEM WHERE are you try to set this? Setting this in a CMakeLists.txt file will not work. Did you read the wiki page[1] about cross-compiling? Check that CMAKE_CROSSCOMPILING is set to true. HS [1]: http://www.cmake.org/Wiki/CMake_Cross_Compiling Thanks, I've read that before posting my first post :-) I tried having toochain.cmake file in the same dir as CMakeLists.txt using cmake -DCMAKE_TOOLCHAIN_FILE=./toolchain.cmake . does not seem to even read that file. I tried to state full path, move the file away, no luck. So I just include()d my toolchain.cmake in CMakeLists.txt. And, yes, CMAKE_CROSSCOMPILING is set to false. I tried to set it to true but it has no effect. By the way, on Linux host CMAKE_TOOLCHAIN_FILE variable doesn't have effect as well. -- Sincerely Yours, Vladimir Lebedev-Schmidthof___ 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 on OS X/x86 for Linux/ARM, linking a library
Zitat von Vladimir Lebedev-Schmidthof : On Oct 19, 2009, at 23:18 PM, Alexander Neundorf wrote: I set CMAKE_SYSTEM to Linux, even added "SET(APPLE 0)" but install_name option is still generating. You should set "CMAKE_SYSTEM_NAME", not "CMAKE_SYSTEM" to "Linux". If you really set CMAKE_SYSTEM instead of CMAKE_SYSTEM_NAME, this will fix your problem (after a quick look it seems install_name is really only set in the Modules/Platform/Darwin*.cmake files, which should not get loaded if CMAKE_SYSTEM_NAME is set to Linux). I tried. Setting CMAKE_SYSTEM_NAME to "Linux" does not seem to affect CMAKE_SYSTEM WHERE are you try to set this? Setting this in a CMakeLists.txt file will not work. Did you read the wiki page[1] about cross-compiling? Check that CMAKE_CROSSCOMPILING is set to true. HS [1]: http://www.cmake.org/Wiki/CMake_Cross_Compiling ___ 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 on OS X/x86 for Linux/ARM, linking a library
Hello Alexander,
On Oct 19, 2009, at 23:18 PM, Alexander Neundorf wrote:
> I set CMAKE_SYSTEM to Linux, even added "SET(APPLE 0)" but
> install_name option is still generating.
You should set "CMAKE_SYSTEM_NAME", not "CMAKE_SYSTEM" to "Linux".
If you
really set CMAKE_SYSTEM instead of CMAKE_SYSTEM_NAME, this will fix
your
problem (after a quick look it seems install_name is really only set
in the
Modules/Platform/Darwin*.cmake files, which should not get loaded if
CMAKE_SYSTEM_NAME is set to Linux).
I tried. Setting CMAKE_SYSTEM_NAME to "Linux" does not seem to affect
CMAKE_SYSTEM
(i.e. adding
-
SET(CMAKE_SYSTEM_NAME "Linux")
...
MESSAGE("CMAKE_SYSTEM_NAME is ${CMAKE_SYSTEM_NAME}")
MESSAGE("CMAKE_SYSTEM is ${CMAKE_SYSTEM}")
-
results to
-
CMAKE_SYSTEM_NAME is Linux
CMAKE_SYSTEM is Darwin-9.8.0
-
Though
-
SET(CMAKE_SYSTEM "Linux")
-
results to
CMAKE_SYSTEM_NAME is Darwin
CMAKE_SYSTEM is Linux
So it seems that I have to set to Linux both variables. Anyway, cmake
keeps adding install_name (and other Darwin-specific things) to linker
options.
___
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 on OS X/x86 for Linux/ARM, linking a library
On Monday 19 October 2009, Vladimir Lebedev-Schmidthof wrote: > Hello everyone, > > Two compiling platforms - Linux and OS X. > Same project, same cmake (2.6.4), same target (Linux/ARM). > > Sources compiles well (GNU C/C++) but linking is different. > > Everything is fine on Linux. > > comparing make VERBOSE=1 outputs: > > OS X: [path-to]/gcc -march=armv5te -mtune=xscale -msoft-float -fpic - > mthumb-interwork -ffunction-sections -funwind-tables -fstack-protector > -fno-short-enums -dynamiclib -nostdlib -Wl,-shared,-Bsymbolic -Wl,- > rpath-link=[path-to]/usr/lib -Wl,--whole-archive -Wl,--no-undefined - > Wl,-rpath-link=[path-to]/usr/lib -o libmylib.so -install_name /Users/ > dair/Project/native/libmylib.so [source-files] > > Linux: [path-to]/gcc -fPIC -march=armv5te -mtune=xscale -msoft-float - > fpic -mthumb-interwork -ffunction-sections -funwind-tables -fstack- > protector -fno-short-enums -nostdlib -Wl,-shared,-Bsymbolic -Wl,-rpath- > link=[path-to]/usr/lib -Wl,--whole-archive -Wl,--no-undefined -Wl,- > rpath-link=[path-to]/usr/lib -shared -Wl,-soname,libmylib.so -o > libmylib.so [source-files] > > The problem is "-install_name" option. Cmake generates that in OS X > but GCC cross-compiler does not accept that. I can successfully link > the library (manually) by removing this option. > > I set CMAKE_SYSTEM to Linux, even added "SET(APPLE 0)" but > install_name option is still generating. You should set "CMAKE_SYSTEM_NAME", not "CMAKE_SYSTEM" to "Linux". If you really set CMAKE_SYSTEM instead of CMAKE_SYSTEM_NAME, this will fix your problem (after a quick look it seems install_name is really only set in the Modules/Platform/Darwin*.cmake files, which should not get loaded if CMAKE_SYSTEM_NAME is set to Linux). Alex ___ 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 arm-elf on Windows host
On Monday 21 September 2009, Harald Kipp wrote: > Alexander Neundorf wrote: > > On Sunday 20 September 2009, Harald Kipp wrote: > >> Alexander Neundorf wrote: > >>> On Sunday 20 September 2009, Harald Kipp wrote: > add_library(nutfs STATIC basename dirent dirname) > > > > I would recommend to use the full filename, i.e. including the suffix. So > > probably basename.c etc. > > Oops, I temporarily removed the extensions after finding make target > extensions like .c.o. > > Scanning dependencies of target nutfs > [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj > Das System kann den angegebenen Pfad nicht finden. > >>> > >>> Try "VERBOSE=1 make" to see the full command which is executed. > >> > >> I'll try to do this tommorrow. > > As expected, make fails at the cd command using slashes instead of > backslashes: > > [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj > cd C:/ethernut-4.9.6/nutbld/fs && > C:/Programme/yagarto/bin/arm-elf-gcc.exe-o > CMakeFiles/nutfs.dir/basename.c.obj -c > C:/ethernut-4.9.6/nut/fs/basename.c Das System kann den angegebenen Pfad > nicht finden. > > (English: The system cannot find the specified path) Is this the make from yagarto ? > make[2]: *** [fs/CMakeFiles/nutfs.dir/basename.c.obj] Error 1 > make[2]: Leaving directory `C:/ethernut-4.9.6/nutbld' > make[1]: *** [fs/CMakeFiles/nutfs.dir/all] Error 2 > make[1]: Leaving directory `C:/ethernut-4.9.6/nutbld' > make: *** [all] Error 2 > > >>> You might try the nmake makefiles in case you have nmake. > >> > >> I'll try this as well. > > Unfortunately no luck. The generated Makefiles cannot be processed by > GNU make, because nmake partly uses a different syntax, like > > !IF "$(OS)" == "Windows_NT" > NULL= > !ELSE > NULL=nul > !ENDIF > > Furthermore it adds the /nologo command line option when calling > $(MAKE), which is rejected by GNU make. Yes, you would have to use nmake to process these makefiles. Which makefile generator do you use ? "Unix Makefiles" ? There are also "MinGW Makefiles" and "MSYS Makefiles". I don't have a Windows here, so I can't test. These three generators all generate makefiles for GNU make under Windows, but differ in things like the directory separators etc. >From the docs for the MinGW one: "Generates a make file for use with mingw32-make."; "The makefiles generated use cmd.exe as the shell. " "They do not require msys or a unix shell."; and for the MSYS one: "Generates MSYS makefiles."; "The makefiles use /bin/sh as the shell. " "They require msys to be installed on the machine."; So the MSYS one is probably not what you want, but MinGW sounds good. Please give it a try. So, you "only" have a problem with finding the right combination of makefile generator and build tools :-) Here you can find a bit more information: http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_generators > >> One reason for looking at CMake as an alternative to GNU autotools is, > >> that we do not want to force Windows users to install Cygwin or force OS > >> X users to install fink. It'd be great if CMake can help here. > > > > Should do. > > Sigh. Right now I do not see the light at the end of the tunnel. May be > I should explain my goal in more detail. > > Our package exists of the RTOS source code, which may be build for > different targets (AVR, ARM, AVR32). Furthermore it contains the source > code of the "Configurator" tool, which creates several C header files > and Makefiles based on a target board config file. Running these > makefiles will create the RTOS for this specific target board. > > Btw. the Configurator is based on the wxWidgets version of the eCos > configtool, but we replaced tcl by Lua. > > On Linux and OS X we use GNU autotools to create the Configurator > executable. On Windows there is no such capability and the average user > must stick with the pre-build executable. > > Then the Configurator must be executed manually to create the header and > Makefile files. Finally make will create the target binaries. These > steps are equal on all host platforms. > > We could have used autotools to create the target binaries as well, but > not on Windows without installing a *nix environment. > > The idea is to use CMake to automatically to > > 1. build the Configurator tool binary, checking the compiler available, > wxWidgets version etc. The first step must be separate from the two following, since it uses a different toolchain, and one buildtree in CMake must (really really should) use only one toolchain. > 2. run the Configurator for a specified target board, creating the C > headers and possibly one or more .cmake files for building the target > binaries > > 3. build the RTOS and sample applications, checking the cross compiler, > target run time library etc. This should work. We just need to get your makefiles work at all. Alex ___ Powered by www.kitwa
Re: [CMake] Cross compiling arm-elf on Windows host
Alexander Neundorf wrote: > On Sunday 20 September 2009, Harald Kipp wrote: >> Alexander Neundorf wrote: >>> On Sunday 20 September 2009, Harald Kipp wrote: add_library(nutfs STATIC basename dirent dirname) > I would recommend to use the full filename, i.e. including the suffix. So > probably basename.c etc. Oops, I temporarily removed the extensions after finding make target extensions like .c.o. Scanning dependencies of target nutfs [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj Das System kann den angegebenen Pfad nicht finden. >>> Try "VERBOSE=1 make" to see the full command which is executed. >> I'll try to do this tommorrow. As expected, make fails at the cd command using slashes instead of backslashes: [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj cd C:/ethernut-4.9.6/nutbld/fs && C:/Programme/yagarto/bin/arm-elf-gcc.exe-o CMakeFiles/nutfs.dir/basename.c.obj -c C:/ethernut-4.9.6/nut/fs/basename.c Das System kann den angegebenen Pfad nicht finden. (English: The system cannot find the specified path) make[2]: *** [fs/CMakeFiles/nutfs.dir/basename.c.obj] Error 1 make[2]: Leaving directory `C:/ethernut-4.9.6/nutbld' make[1]: *** [fs/CMakeFiles/nutfs.dir/all] Error 2 make[1]: Leaving directory `C:/ethernut-4.9.6/nutbld' make: *** [all] Error 2 >>> You might try the nmake makefiles in case you have nmake. >> I'll try this as well. Unfortunately no luck. The generated Makefiles cannot be processed by GNU make, because nmake partly uses a different syntax, like !IF "$(OS)" == "Windows_NT" NULL= !ELSE NULL=nul !ENDIF Furthermore it adds the /nologo command line option when calling $(MAKE), which is rejected by GNU make. >> One reason for looking at CMake as an alternative to GNU autotools is, >> that we do not want to force Windows users to install Cygwin or force OS >> X users to install fink. It'd be great if CMake can help here. > > Should do. Sigh. Right now I do not see the light at the end of the tunnel. May be I should explain my goal in more detail. Our package exists of the RTOS source code, which may be build for different targets (AVR, ARM, AVR32). Furthermore it contains the source code of the "Configurator" tool, which creates several C header files and Makefiles based on a target board config file. Running these makefiles will create the RTOS for this specific target board. Btw. the Configurator is based on the wxWidgets version of the eCos configtool, but we replaced tcl by Lua. On Linux and OS X we use GNU autotools to create the Configurator executable. On Windows there is no such capability and the average user must stick with the pre-build executable. Then the Configurator must be executed manually to create the header and Makefile files. Finally make will create the target binaries. These steps are equal on all host platforms. We could have used autotools to create the target binaries as well, but not on Windows without installing a *nix environment. The idea is to use CMake to automatically to 1. build the Configurator tool binary, checking the compiler available, wxWidgets version etc. 2. run the Configurator for a specified target board, creating the C headers and possibly one or more .cmake files for building the target binaries 3. build the RTOS and sample applications, checking the cross compiler, target run time library etc. Thanks again for your time, Harald ___ 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 arm-elf on Windows host
On Sunday 20 September 2009, Harald Kipp wrote: > Alexander Neundorf wrote: > > On Sunday 20 September 2009, Harald Kipp wrote: > >> My subdir CMakeLists: > >> > >> --- C:\ethernut-4.9.6\nut\fs\CMakeLists.txt --- > >> add_library(nutfs STATIC basename dirent dirname) > > > > This command means that you want to build a library called "nutfs" from > > the source files "basename", "dirent" and "dirname". Is this what you > > want ? > > Yes. Actually there are more files, but I wanted to start with these > simple ones first. I would recommend to use the full filename, i.e. including the suffix. So probably basename.c etc. > The directory structure is > > C:\ethernut-4.9.6 > nut <- Source tree > fs <- nutlibfs sources > <- other sources > > >> cmake -G "Unix Makefiles" > >> -DCMAKE_TOOLCHAIN_FILE=c:\ethernut-4.9.6\toolchain-generic.cmake > >> c:\ethernut-4.9.6\nut > >> > >> So far the result is > >> > >> -- Configuring done > >> -- Generating done > >> -- Build files have been written to: C:/ethernut-4.9.6/nutbld > >> > >> However, when trying to run make, I get > > > > What "make" is it ? cygwin ? mingw ? > > Generally we use > http://www.yagarto.de/ > for building arm-elf binaries on Windows. YAGARTO is build with mingw. > However, the Ethernut developers do not need to install cygwin or mingw. > So far all binaries run on a native Windows command shell. I'm not completely sure here. I think if you generate "Unix Makefiles" on Windows you may need to execute it from a mingw shell or something like this. But I'm not sure. > >> Scanning dependencies of target nutfs > >> [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj > >> Das System kann den angegebenen Pfad nicht finden. > > > > Try "VERBOSE=1 make" to see the full command which is executed. > > I'll try to do this tommorrow. > > >> cd C:/ethernut-4.9.6/nutbld && "C:/Programm > >> > >> I think that this will not work on Windows. cd requires backslashes. > > > > I think this depends on the type of makefiles you generate and on the > > type of make/shell you use to execute them. > > You might try the nmake makefiles in case you have nmake. > > I'll try this as well. > > One reason for looking at CMake as an alternative to GNU autotools is, > that we do not want to force Windows users to install Cygwin or force OS > X users to install fink. It'd be great if CMake can help here. Should do. Alex ___ 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 arm-elf on Windows host
Alexander Neundorf wrote: > On Sunday 20 September 2009, Harald Kipp wrote: >> My subdir CMakeLists: >> >> --- C:\ethernut-4.9.6\nut\fs\CMakeLists.txt --- >> add_library(nutfs STATIC basename dirent dirname) > > This command means that you want to build a library called "nutfs" from the > source files "basename", "dirent" and "dirname". Is this what you want ? Yes. Actually there are more files, but I wanted to start with these simple ones first. The directory structure is C:\ethernut-4.9.6 nut <- Source tree fs <- nutlibfs sources <- other sources >> cmake -G "Unix Makefiles" >> -DCMAKE_TOOLCHAIN_FILE=c:\ethernut-4.9.6\toolchain-generic.cmake >> c:\ethernut-4.9.6\nut >> >> So far the result is >> >> -- Configuring done >> -- Generating done >> -- Build files have been written to: C:/ethernut-4.9.6/nutbld >> >> However, when trying to run make, I get > > What "make" is it ? cygwin ? mingw ? Generally we use http://www.yagarto.de/ for building arm-elf binaries on Windows. YAGARTO is build with mingw. However, the Ethernut developers do not need to install cygwin or mingw. So far all binaries run on a native Windows command shell. >> Scanning dependencies of target nutfs >> [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj >> Das System kann den angegebenen Pfad nicht finden. > > Try "VERBOSE=1 make" to see the full command which is executed. I'll try to do this tommorrow. >> cd C:/ethernut-4.9.6/nutbld && "C:/Programm >> >> I think that this will not work on Windows. cd requires backslashes. > > I think this depends on the type of makefiles you generate and on the type of > make/shell you use to execute them. > You might try the nmake makefiles in case you have nmake. I'll try this as well. One reason for looking at CMake as an alternative to GNU autotools is, that we do not want to force Windows users to install Cygwin or force OS X users to install fink. It'd be great if CMake can help here. Many thanks so far for your prompt reply, Harald ___ 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 arm-elf on Windows host
On Sunday 20 September 2009, Harald Kipp wrote: > Hi all, > > I'm considering CMake for our Ethernut project > http://www.ethernut.de > > In a first step I tried to build a simple library for an arm-elf target. > I tried to follow > http://www.itk.org/Wiki/CMake_Cross_Compiling > as well as > http://www.itk.org/Wiki/CmakeEcos > > Unfortunately nothing worked here. :-( > > The eCos sample is obviously targeted for Linux hosts. Yes. When I was working with eCos, we used either Linux or cygwin as development platform. Not sure if there may be issues with the eCos tools if you are not using cygwin. > After several hours of trial and error I managed to get a few things > working, but still no library build. > > I decided to cut everything back to pure minimum. > > My toolchain file: > > --- C:\ethernut-4.9.6\toolchain-generic.cmake --- > INCLUDE(CMakeForceCompiler) > SET(CMAKE_SYSTEM_NAME Generic) > SET(CMAKE_SYSTEM_PROCESSOR arm7tdmi) > CMAKE_FORCE_C_COMPILER(arm-elf-gcc GNU) > CMAKE_FORCE_CXX_COMPILER(arm-elf-g++ GNU) > - > > My top CMakeLists: > > --- C:\ethernut-4.9.6\nut\CMakeLists.txt --- > cmake_minimum_required(VERSION 2.6) > add_subdirectory(fs) > > > My subdir CMakeLists: > > --- C:\ethernut-4.9.6\nut\fs\CMakeLists.txt --- > add_library(nutfs STATIC basename dirent dirname) This command means that you want to build a library called "nutfs" from the source files "basename", "dirent" and "dirname". Is this what you want ? > --- > > My command sequence: > > cd C:\ethernut-4.9.6 > mkdir nutbld > cd nutbld > > then > > cmake -G "Unix Makefiles" > -DCMAKE_TOOLCHAIN_FILE=c:\ethernut-4.9.6\toolchain-generic.cmake > c:\ethernut-4.9.6\nut > > So far the result is > > -- Configuring done > -- Generating done > -- Build files have been written to: C:/ethernut-4.9.6/nutbld > > However, when trying to run make, I get What "make" is it ? cygwin ? mingw ? > Scanning dependencies of target nutfs > [ 33%] Building C object fs/CMakeFiles/nutfs.dir/basename.c.obj > Das System kann den angegebenen Pfad nicht finden. Try "VERBOSE=1 make" to see the full command which is executed. > make[2]: *** [fs/CMakeFiles/nutfs.dir/basename.c.obj] Error 1 > make[1]: *** [fs/CMakeFiles/nutfs.dir/all] Error 2 > make: *** [all] Error 2 > > Furthermore, when > > cd fs > make -n > > gives > > cd C:/ethernut-4.9.6/nutbld && "C:/Programm > > I think that this will not work on Windows. cd requires backslashes. I think this depends on the type of makefiles you generate and on the type of make/shell you use to execute them. You might try the nmake makefiles in case you have nmake. Alex ___ 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 with FindQt4.cmake
On Friday 19 June 2009, Hendrik Sattler wrote: > Hi, > > FindQt4 seems to _completely_ fail for cross-compiling as it depends on > running qmake. As it finds the hosts qmake executable, all it gets is wrong > information. yes, it queries qmake, and since qmake must run on the build host, this will not be the information for the target system. Some work has to be put in this file to make it support cross compiling. Alex ___ 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 with FindQt4.cmake
Am Freitag 19 Juni 2009 21:13:14 schrieb Clinton Stimpson: > To cross-compile Qt apps, you still need to be able to run at least uic, > moc, and maybe other tools. > > I've done it before (way back when cross-compiling support was first > added to cmake). > What I did was compile Qt for the target platform, and again for the > native platform using the same install prefix for both. I installed the > target platform Qt, then copied qmake/uic/moc/etc... from the native one > into the first installation. > > Is there an official way to cross-compile Qt that is different than what > I did? > With that, could you use qmake generated makefiles (which assumes you > can run qmake natively)? I cross-compile from Debian to Windows. QT 4.5 is isntalled for the Debian system and I use the precompiled Qt-4.0.1 from the Qt website. I could use he newer uic and moc (both not absolutely needed) but qmake will not give the right output. Because it asks qmake for library and include dirs, even when I compile the same version for the host, those answers will be wrong as they do not target the target root dir. Also, the module is so damn sure about qmake output that it sets NO_DEFAULT_PATH when trying to find stuff. This is even more wrong in this situation. It seems that FindQt4.cmake wasn't ever updated with cross-compiling as focus. HS ___ 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 with FindQt4.cmake
To cross-compile Qt apps, you still need to be able to run at least uic, moc, and maybe other tools. I've done it before (way back when cross-compiling support was first added to cmake). What I did was compile Qt for the target platform, and again for the native platform using the same install prefix for both. I installed the target platform Qt, then copied qmake/uic/moc/etc... from the native one into the first installation. Is there an official way to cross-compile Qt that is different than what I did? With that, could you use qmake generated makefiles (which assumes you can run qmake natively)? Clint Hendrik Sattler wrote: Hi, FindQt4 seems to _completely_ fail for cross-compiling as it depends on running qmake. As it finds the hosts qmake executable, all it gets is wrong information. Can this be solved somehow? Thanks... HS ___ 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 ___ 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 with FindQt4.cmake
On Fri, Jun 19, 2009 at 09:00:24PM +0200, Hendrik Sattler wrote: > FindQt4 seems to _completely_ fail for cross-compiling as it depends on > running qmake. As it finds the hosts qmake executable, all it gets is wrong > information. Not sure I understand the problem but you can use CMAKE_PREFIX_PATH to help FindQt4 locate the qmake you want it to find. This means you need to have the qmake for your cross-compile target available from your build host, but your 3rd party libraries are already in a single common repository, right? tyler ___ 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 for QNX
> I've been using QNX and cmake together for a few weeks, and I've yet to
> have the problem that you indicated. In my QNX toolchain file I use the
> line:
>
> SET( CMAKE_AR
> "${QNX_HOST}/usr/bin/ntox86-ar${HOST_EXECUTABLE_SUFFIX}" CACHE PATH "QNX
ar Program" )
>
> -kito
Thanks for the help, that has solved the problem. I guess I got side-tracked
with the symptom that the placement of SET(CMAKE_AR "ntox86-ar.exe") in the
QNX.cmake file worked, but the same string in the toolchain file didn't. So
what wasn't clear was that it needed to have an absolute path and couldn't
search for this exe in the CMAKE_FIND_ROOT_PATH (like it seems to do for the
default string "ar.exe").
I have one last problem that you may be able to help me out with? When
linking shared libraries the cmake generated make output "cmake -E
cmake_symlink_library" fails with an Error but doesn't explain why. I've
done some searching but can't find what could be the problem! Just wondering
if you build shared libraries with symlinks and have experienced something
similar?
Thanks, Ross
___
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 for QNX (ross hennessy)
I've been using QNX and cmake together for a few weeks, and I've yet to
have the problem that you indicated. In my QNX toolchain file I use the
line:
SET( CMAKE_AR
"${QNX_HOST}/usr/bin/ntox86-ar${HOST_EXECUTABLE_SUFFIX}" CACHE PATH
"QNX ar Program" )
-kito
Message: 5
Date: Wed, 25 Mar 2009 14:10:30 +1100
From: ross hennessy
Subject: [CMake] cross compiling for QNX
To: CMake@cmake.org
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
I'm having a problem creating a toolchain file for use with cmake 2.6.3.
I'd
like to generate a UnixMakefile compatible with the QNX Momentics cross
platform development tools. The problem is cmake doesn't seem to find
the
archiver which is named ntox86-ar.exe (as QNX runs on multiple platforms
there are many different versions of the archiver for each target). No
placement of SET(CMAKE_AR "ntox86-ar.exe") in the toolchain file seems
to
help. There is two solutions that I have found so far, neither of which
I'm
particularly happy with. They are -
1) making a copy of ntox86-ar.exe in the momentics install and renaming
it
to ar.exe (which is obviously what cmake is looking for, but totally
wrong
in the context of using a system which is designed for many targets)
2) modifying the QNX.cmake file in the platforms directory and adding
the
above SET command (again I would have to modify this every time I wanted
to
build for a new target)
I would like to be able to specify this in the toolchain file as it is
my
understanding that this is what this file is intended for. Am I doing
something wrong here, or is this the expected behaviour of cmake?
Thanks, Ross
-- next part --
An HTML attachment was scrubbed...
URL:
___
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 toolchain: Substitution in variable
On Wednesday 17 September 2008, Simon Barner wrote:
> Dear CMake users list,
>
> I am currently development a CMake cross build platform
> definition to support Microchips C18 C compiler[1].
>
> I encountered the problem that C18's linker does not like '/' as
> path delimiter which is why I need some substitution for the
> filenames contained in the "magic" variable (to '\').
>
> The only solution I found is to create a temporary batch file and
> to use cmd's text replacement facilities.
>
> Here is the platform file in question:
> CMake version: 2.6.1
> CMake generator: Unix Makefiles
> Build platform: win32 (Vista)
>
>
> # Suffixes of static libraries and object files created by us
> SET(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
> SET(CMAKE_C_OUTPUT_EXTENSION ".o")
>
> SET(CMAKE_C_LINK_EXECUTABLE mplink.exe)
> SET(CMAKE_AR mplib.exe)
>
> # Linking against static variables: /l path/to/lib libTheLibrary.lib
> SET(CMAKE_LIBRARY_PATH_FLAG "/l")
> SET(CMAKE_LINK_LIBRARY_FLAG "lib")
> SET(CMAKE_LINK_LIBRARY_SUFFIX ".lib")
>
> # Compile a C file into an object file
> SET(CMAKE_C_COMPILE_OBJECT " -O
> -fo=\\\"\\\" ")
>
> # Link object files to an executable
> SET(CMAKE_C_LINK_EXECUTABLE "
> /o /w")
>
> # Create static library
> # Problem 1: APPEND does not work (not invoked?)
> # --> do all work in CREATE
> # Problem 2: Need to use \ as path delimiter in .
> # Is text replacement possible?
No (at least if I understand correctly).
> #SET (CMAKE_C_ARCHIVE_CREATE " /c ; /r
> ")
> #SET (CMAKE_C_ARCHIVE_APPEND "echo append")
>
> # Create static library
> #
> # Caution: Object paths to be passed to mplib must use
> # '\' as path delimiter!
> # TODO: Using temporary batch file to perform text replacement / --> \
> SET(CMAKE_C_CREATE_STATIC_LIBRARY
> "\"${CMAKE_COMMAND}\" -E remove "
> "\"${CMAKE_COMMAND}\" -E remove c18_build_archive.bat"
> " /c "
> "echo set objs= > c18_build_archive.bat"
> "echo /r %%objs:/=\\%% >> c18_build_archive.bat"
> "c18_build_archive.bat"
> "\"${CMAKE_COMMAND}\" -E remove c18_build_archive.bat"
> )
> ===
>
> As you can see, there is also a minor problem with
> CMAKE_C_ARCHIVE_APPEND not being invoked. I tried to work around the
> latter issue by using cmd's ; operator in CMAKE_C_ARCHIVE_CREATE.
>
> Could you please give my some piece of advice, especially for the text
> substitution problem? As soon as I have a clean solution, I would
> certainly like to submit the platform definition file to the CMake
> distribution.
>
> Here is how I invoke CMake:
>
> cmake -G "Unix Makefiles"
>-D "CMAKE_TOOLCHAIN_FILE:FILEPATH=Toolchain-C18.cmake"
I'm not too familiar with the differences of the makefile generators for
Windows. Can you try if you also get slashes if you use the nmake makefile
generator together with nmake ?
> === Toolchain-C18.cmake ===
> INCLUDE(CMakeForceCompiler)
>
> SET(CMAKE_SYSTEM_NAME Generic)
> CMAKE_FORCE_C_COMPILER(mcc18.exe MicrochipC18)
Why do you need the CMAKE_FORCE_C_COMPILER() ?
It should only be necessary in very rare conditions.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross compiling toolchain: Substitution in variable
Hi,
does anybody have a clue on this? Or should I re-state
my question?
Thanks,
Simon
I am currently development a CMake cross build platform
definition to support Microchips C18 C compiler[1].
I encountered the problem that C18's linker does not like '/' as
path delimiter which is why I need some substitution for the
filenames contained in the "magic" variable (to '\').
The only solution I found is to create a temporary batch file and
to use cmd's text replacement facilities.
Here is the platform file in question:
CMake version: 2.6.1
CMake generator: Unix Makefiles
Build platform: win32 (Vista)
# Suffixes of static libraries and object files created by us
SET(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
SET(CMAKE_C_OUTPUT_EXTENSION ".o")
SET(CMAKE_C_LINK_EXECUTABLE mplink.exe)
SET(CMAKE_AR mplib.exe)
# Linking against static variables: /l path/to/lib libTheLibrary.lib
SET(CMAKE_LIBRARY_PATH_FLAG "/l")
SET(CMAKE_LINK_LIBRARY_FLAG "lib")
SET(CMAKE_LINK_LIBRARY_SUFFIX ".lib")
# Compile a C file into an object file
SET(CMAKE_C_COMPILE_OBJECT " -O
-fo=\\\"\\\" ")
# Link object files to an executable
SET(CMAKE_C_LINK_EXECUTABLE "
/o /w")
# Create static library
# Problem 1: APPEND does not work (not invoked?)
# --> do all work in CREATE
# Problem 2: Need to use \ as path delimiter in .
# Is text replacement possible?
#SET (CMAKE_C_ARCHIVE_CREATE " /c ; /r
")
#SET (CMAKE_C_ARCHIVE_APPEND "echo append")
# Create static library
#
# Caution: Object paths to be passed to mplib must use
# '\' as path delimiter!
# TODO: Using temporary batch file to perform text replacement / --> \
SET(CMAKE_C_CREATE_STATIC_LIBRARY
"\"${CMAKE_COMMAND}\" -E remove "
"\"${CMAKE_COMMAND}\" -E remove c18_build_archive.bat"
" /c "
"echo set objs= > c18_build_archive.bat"
"echo /r %%objs:/=\\%% >> c18_build_archive.bat"
"c18_build_archive.bat"
"\"${CMAKE_COMMAND}\" -E remove c18_build_archive.bat"
)
===
As you can see, there is also a minor problem with
CMAKE_C_ARCHIVE_APPEND not being invoked. I tried to work around the
latter issue by using cmd's ; operator in CMAKE_C_ARCHIVE_CREATE.
Could you please give my some piece of advice, especially for the text
substitution problem? As soon as I have a clean solution, I would
certainly like to submit the platform definition file to the CMake
distribution.
Here is how I invoke CMake:
cmake -G "Unix Makefiles"
-D "CMAKE_TOOLCHAIN_FILE:FILEPATH=Toolchain-C18.cmake"
=== Toolchain-C18.cmake ===
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER(mcc18.exe MicrochipC18)
=
--
Lehrstuhl für Dipl.-Inf. Simon Barner
Robotik und eingebettete Systeme Technische Universitaet Muenchen
Fakultaet fuer Informatik
Lehrstuhl I/6 Boltzmannstrasse 3 85748 Garching http://www6.in.tum.de
Tel.: ++49 (0)89 289-18111 Fax: -18107 Email: [EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
Thanks; I gave up on trying to get long filenames to work. There are too many
levels involved, and if you get it right on 1-n, then n+1 messes it up, etc.,
etc.
Right, the I took out the FORCE_C_COMPILER stuff. But it still breaks things it
shouldn't.
z/OS is indeed not the only OS on System z; that's why I was asking before
about the nomenclature (OS vs. platform etc.). The good news is, anybody on
System z knows about z/OS and knows that it's the "big dog", so we're OK using
that name, rather than ANY_SYSTEM_Z_OS or something (!). (I came from the
world of one of the other System z OSes, so I think I can say that with some
confidence: we've spent decades reminding people that "z/OS" isn't the only OS,
but given that we have to choose something...)
Once this finally settles down once and for all (we're still fighting other
fires, but I think CMake is a resolved issue) I'll look into submitting a patch.
Related question: I hacked CheckTypeSize.cmake to MESSAGE the OUTPUT variable
after a compile, since it was claiming to work but actually failing (leaving no
values for the types in CMakeCache.txt). Some grepping of the CMAKE files and
the source failed to reveal any way that the --debug_output flag was exposed to
the macros; did I miss it? It would be nice to have a way to see the compiler
output.
...phsiii
-Original Message-
From: Alexander Neundorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 6:04 PM
To: Phil Smith
Cc: cmake@cmake.org
Subject: Re: [CMake] Cross-compiling for z/OS -- linker question
On Monday 25 August 2008, Phil Smith wrote:
> I'm back on this, after a week at a conference and a week of vacation.
>
> I have the GET_FILENAME_COMPONENT call working, and it returns what I'd
> expect (c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with
> blanks (c:/Program Files/Dignus/plink.exe). Here's the CMAKE code I'm
> using, in ZOS.cmake:
>
> GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
> MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
> FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}"
> NO_DEFAULT_PATH) MESSAGE(STATUS "PLINK_EXECUTABLE is ${PLINK_EXECUTABLE}!")
> SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
> SET(CMAKE_C_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
>
> That barfs all over the place. The two MESSAGE calls show:
> -- PLINK path is c:/progra~1/dignus!
> -- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
> (And if I put the "progra~1"-format path back in manually, it works again.)
Hmm, the output from MESSAGE() looks as I would expect. What's wrong with
it/what exactly does "barfs all over the place" mean ?
> I also realized that I think there will be a change needed to
> CheckTypeSize.cmake after all: the -fasciiout flag only makes sense during
> that call, as during actual compiles, one will NOT want it set. Something
> like (around line 60): IF(ZOS)
> SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
> -fasciiout") ENDIF(ZOS)
Hmm, looks ugly but maybe we'll have to do something like this :-/
> Finally, I'm also still trying to figure out how to name things most
correctly. You said a couple of things before:
> >Well, the initial tests for the compiler should work without the
> >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in
> > cmake should be able to detect that it's the Dignus compiler, and set
> >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load
> >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
> >These files should then contain the settings which are specific for that
> >combination of operating system, and compiler.
> >E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
>
> and:
> > No, it's --.cmake
> >with SYSTEM being the name of the operating system.
>
> But what I don't see is how it's going to figure out that the compiler is
> named Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything.
"breaks everything" ?
Aren't we trying right now to get rid of the FORCE_C_COMPILER stuff ? It
shouldn't break anything, since it's not called anymore :-)
> Maybe I don't care that much that the compiler gets identified fully -- do
> I? It's the one and only likely compiler to be used for z, now and forever
But I guess zOS is not the only OS the compiler can be used for ?
So getting this to work should help using Dignus on other platforms.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
${PLINK_EXECUTABLE} contains spaces...
Maybe you need escaped quotes:
SET(CMAKE_CXX_LINK_EXECUTABLE "\"${PLINK_EXECUTABLE}\"
\" around the executable variable reference...?
On Wed, Sep 3, 2008 at 6:04 PM, Alexander Neundorf
<[EMAIL PROTECTED]>wrote:
> On Monday 25 August 2008, Phil Smith wrote:
> > I'm back on this, after a week at a conference and a week of vacation.
> >
> > I have the GET_FILENAME_COMPONENT call working, and it returns what I'd
> > expect (c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with
> > blanks (c:/Program Files/Dignus/plink.exe). Here's the CMAKE code I'm
> > using, in ZOS.cmake:
> >
> > GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
> > MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
> > FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}"
> > NO_DEFAULT_PATH) MESSAGE(STATUS "PLINK_EXECUTABLE is
> ${PLINK_EXECUTABLE}!")
> > SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> > \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
> > SET(CMAKE_C_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> > \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
> >
> > That barfs all over the place. The two MESSAGE calls show:
> > -- PLINK path is c:/progra~1/dignus!
> > -- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
> > (And if I put the "progra~1"-format path back in manually, it works
> again.)
>
> Hmm, the output from MESSAGE() looks as I would expect. What's wrong with
> it/what exactly does "barfs all over the place" mean ?
>
> > I also realized that I think there will be a change needed to
> > CheckTypeSize.cmake after all: the -fasciiout flag only makes sense
> during
> > that call, as during actual compiles, one will NOT want it set.
> Something
> > like (around line 60): IF(ZOS)
> > SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
> > -fasciiout") ENDIF(ZOS)
>
> Hmm, looks ugly but maybe we'll have to do something like this :-/
>
> > Finally, I'm also still trying to figure out how to name things most
> correctly. You said a couple of things before:
> > >Well, the initial tests for the compiler should work without the
> > >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in
> > > cmake should be able to detect that it's the Dignus compiler, and set
> > >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to
> load
> > >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
> > >These files should then contain the settings which are specific for that
> > >combination of operating system, and compiler.
> > >E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
> >
> > and:
> > > No, it's --.cmake
> > >with SYSTEM being the name of the operating system.
> >
> > But what I don't see is how it's going to figure out that the compiler is
> > named Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything.
>
> "breaks everything" ?
> Aren't we trying right now to get rid of the FORCE_C_COMPILER stuff ? It
> shouldn't break anything, since it's not called anymore :-)
>
> > Maybe I don't care that much that the compiler gets identified fully --
> do
> > I? It's the one and only likely compiler to be used for z, now and
> forever
>
> But I guess zOS is not the only OS the compiler can be used for ?
> So getting this to work should help using Dignus on other platforms.
>
> Alex
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
On Monday 25 August 2008, Phil Smith wrote:
> I'm back on this, after a week at a conference and a week of vacation.
>
> I have the GET_FILENAME_COMPONENT call working, and it returns what I'd
> expect (c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with
> blanks (c:/Program Files/Dignus/plink.exe). Here's the CMAKE code I'm
> using, in ZOS.cmake:
>
> GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
> MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
> FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}"
> NO_DEFAULT_PATH) MESSAGE(STATUS "PLINK_EXECUTABLE is ${PLINK_EXECUTABLE}!")
> SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
> SET(CMAKE_C_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
>
> That barfs all over the place. The two MESSAGE calls show:
> -- PLINK path is c:/progra~1/dignus!
> -- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
> (And if I put the "progra~1"-format path back in manually, it works again.)
Hmm, the output from MESSAGE() looks as I would expect. What's wrong with
it/what exactly does "barfs all over the place" mean ?
> I also realized that I think there will be a change needed to
> CheckTypeSize.cmake after all: the -fasciiout flag only makes sense during
> that call, as during actual compiles, one will NOT want it set. Something
> like (around line 60): IF(ZOS)
> SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
> -fasciiout") ENDIF(ZOS)
Hmm, looks ugly but maybe we'll have to do something like this :-/
> Finally, I'm also still trying to figure out how to name things most
correctly. You said a couple of things before:
> >Well, the initial tests for the compiler should work without the
> >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in
> > cmake should be able to detect that it's the Dignus compiler, and set
> >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load
> >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
> >These files should then contain the settings which are specific for that
> >combination of operating system, and compiler.
> >E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
>
> and:
> > No, it's --.cmake
> >with SYSTEM being the name of the operating system.
>
> But what I don't see is how it's going to figure out that the compiler is
> named Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything.
"breaks everything" ?
Aren't we trying right now to get rid of the FORCE_C_COMPILER stuff ? It
shouldn't break anything, since it's not called anymore :-)
> Maybe I don't care that much that the compiler gets identified fully -- do
> I? It's the one and only likely compiler to be used for z, now and forever
But I guess zOS is not the only OS the compiler can be used for ?
So getting this to work should help using Dignus on other platforms.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
I'm back on this, after a week at a conference and a week of vacation.
I have the GET_FILENAME_COMPONENT call working, and it returns what I'd expect
(c:/progra~1/dignus), but the FIND_PROGRAM resolves the path with blanks
(c:/Program Files/Dignus/plink.exe). Here's the CMAKE code I'm using, in
ZOS.cmake:
GET_FILENAME_COMPONENT(PLINKPATH "${CMAKE_C_COMPILER}" PATH)
MESSAGE(STATUS "PLINK path is ${PLINKPATH}!")
FIND_PROGRAM(PLINK_EXECUTABLE NAMES plink PATHS "${PLINKPATH}" NO_DEFAULT_PATH)
MESSAGE(STATUS "PLINK_EXECUTABLE is ${PLINK_EXECUTABLE}!")
SET(CMAKE_CXX_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
\"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
SET(CMAKE_C_LINK_EXECUTABLE "${PLINK_EXECUTABLE}
\"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
That barfs all over the place. The two MESSAGE calls show:
-- PLINK path is c:/progra~1/dignus!
-- PLINK_EXECUTABLE is C:/Program Files/Dignus/plink.exe!
(And if I put the "progra~1"-format path back in manually, it works again.)
You're right about the INCLUDE line, btw -- I had put it in as a minimal entry,
but I see that it's useless to me.
I also realized that I think there will be a change needed to
CheckTypeSize.cmake after all: the -fasciiout flag only makes sense during that
call, as during actual compiles, one will NOT want it set. Something like
(around line 60):
IF(ZOS)
SET(MACRO_CHECK_TYPE_SIZE_FLAGS "${MACRO_CHECK_TYPE_SIZE_FLAGS}
-fasciiout")
ENDIF(ZOS)
Finally, I'm also still trying to figure out how to name things most correctly.
You said a couple of things before:
>Well, the initial tests for the compiler should work without the
>CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in cmake
>should be able to detect that it's the Dignus compiler, and set
>CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load
>Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake).
>These files should then contain the settings which are specific for that
>combination of operating system, and compiler.
>E.g CMAKE_C_LINK_EXECUTABLE and maybe more.
and:
> No, it's --.cmake
>with SYSTEM being the name of the operating system.
But what I don't see is how it's going to figure out that the compiler is named
Dignus, since the CMAKE_FORCE_C_COMPILER stuff breaks everything. Maybe I don't
care that much that the compiler gets identified fully -- do I? It's the one
and only likely compiler to be used for z, now and forever (famous last words,
I know...). At least, if any other got used, it would likely be gcc or some
other, already-identifiable compiler. What's the real benefit of identifying
it, when I can get it to work as-is?
...phsiii
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander
Neundorf
Sent: Saturday, August 09, 2008 8:10 AM
To: cmake@cmake.org
Subject: Re: [CMake] Cross-compiling for z/OS -- linker question
> and zosport.cmake contains (comments/whitespace stripped):
>
> SET(CMAKE_SYSTEM_NAME "ZOS")
> SET(CMAKE_C_COMPILER "c:/progra~1/dignus/cc.bat" "-fasciiout")
> SET(CMAKE_CXX_COMPILER "c:/progra~1/dignus/cxx.bat" "-fasciiout")
> SET(CMAKE_CXX_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
> SET(CMAKE_C_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe
> \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ")
>
> From reading http://www.cmake.org/Wiki/CMake_Cross_Compiling, it appears
> to me that I need at least the first 3 lines of this. And since the other
> two lines have paths in them (even with the "progra~1" format in PATH,
> Windows resolves them as "Program Files", so it fails), I don't think it
> makes sense to put them in Modules/Platform.
In Modules/Platform you can rely on having the full path to the compiler, so
you can use get_filename_component( ... PATH) to get the directory, and then
use the following to get the full path to the linker:
find_program(PLINK_EXECUTABLE NAMES plink
PATHS ...path from above NO_DEFAULT_PATH)
This would keep the specific path in your toolchain file, and the linker can be
found in the zos.cmake file.
The two rules for the link command should also go into that file (or zos-
Dignus-C[XX].cmake.
> So I *think* the only contribution to the CVS tree will be the really
> exciting zos.cmake:
>
> INCLUDE(Platform/UnixPaths)
Are you actually sure about this line ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
> and zosport.cmake contains (comments/whitespace stripped): > > SET(CMAKE_SYSTEM_NAME "ZOS") > SET(CMAKE_C_COMPILER "c:/progra~1/dignus/cc.bat" "-fasciiout") > SET(CMAKE_CXX_COMPILER "c:/progra~1/dignus/cxx.bat" "-fasciiout") > SET(CMAKE_CXX_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe \"- Sc:/progra~1/dignus/objs_rent/&M\" -o ") > SET(CMAKE_C_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe \"- Sc:/progra~1/dignus/objs_rent/&M\" -o ") > > From reading http://www.cmake.org/Wiki/CMake_Cross_Compiling, it appears > to me that I need at least the first 3 lines of this. And since the other > two lines have paths in them (even with the "progra~1" format in PATH, > Windows resolves them as "Program Files", so it fails), I don't think it > makes sense to put them in Modules/Platform. In Modules/Platform you can rely on having the full path to the compiler, so you can use get_filename_component( ... PATH) to get the directory, and then use the following to get the full path to the linker: find_program(PLINK_EXECUTABLE NAMES plink PATHS ...path from above NO_DEFAULT_PATH) This would keep the specific path in your toolchain file, and the linker can be found in the zos.cmake file. The two rules for the link command should also go into that file (or zos- Dignus-C[XX].cmake. > So I *think* the only contribution to the CVS tree will be the really > exciting zos.cmake: > > INCLUDE(Platform/UnixPaths) Are you actually sure about this line ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
>Well, the initial tests for the compiler should work without the >CMakeForceCompiler stuff. If this works, then CMakeC[XX]CompilerId.c.in cmake >should be able to detect that it's the Dignus compiler, and set >CMAKE_C_COMPILER_ID to "Dignus". Once this is works, it then tries to load >Modules/Platform/ZOS-Dignus-C.cmake (and ZOS-Dignus-CXX.cmake). >These files should then contain the settings which are specific for that >combination of operating system, and compiler. >E.g CMAKE_C_LINK_EXECUTABLE and maybe more. Ok, we got it all working. My colleague had something funky with the path on his machine, and ... well, it's past now. Now I'm trying to reconcile doing this the "right" way. I invoke CMAKE with a Toolchain file: cmake -DCMAKE_TOOLCHAIN_FILE:string="zosport.cmake" -G"Unix Makefiles" and zosport.cmake contains (comments/whitespace stripped): SET(CMAKE_SYSTEM_NAME "ZOS") SET(CMAKE_C_COMPILER "c:/progra~1/dignus/cc.bat" "-fasciiout") SET(CMAKE_CXX_COMPILER "c:/progra~1/dignus/cxx.bat" "-fasciiout") SET(CMAKE_CXX_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ") SET(CMAKE_C_LINK_EXECUTABLE "c:/progra~1/dignus/plink.exe \"-Sc:/progra~1/dignus/objs_rent/&M\" -o ") >From reading http://www.cmake.org/Wiki/CMake_Cross_Compiling, it appears to me >that I need at least the first 3 lines of this. And since the other two lines >have paths in them (even with the "progra~1" format in PATH, Windows resolves >them as "Program Files", so it fails), I don't think it makes sense to put >them in Modules/Platform. So I *think* the only contribution to the CVS tree will be the really exciting zos.cmake: INCLUDE(Platform/UnixPaths) Does this sound correct? I'll also document it in the Wiki somewhere (suggestions welcome for the right place to put it), explaining the zosport.cmake and the .bat files. Maybe I should call it zOS-Dignus.cmake just to be sort of more consistent? ...phsiii ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
On Wednesday 06 August 2008, Phil Smith wrote: > OK, once I get it working for real, I'll do this. :-) > But I think I confused you. ZOS is the OS (really z/OS). System z is the > hardware platform. Dignus is the compiler. > > So shouldn't the files be named Systemz-Dignus-C.cmake etc.? No, it's --.cmake with SYSTEM being the name of the operating system. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-compiling for z/OS -- linker question
OK, once I get it working for real, I'll do this. But I think I confused you. ZOS is the OS (really z/OS). System z is the hardware platform. Dignus is the compiler. So shouldn't the files be named Systemz-Dignus-C.cmake etc.? ...phsiii -Original Message- From: Alexander Neundorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2008 5:32 PM To: Phil Smith Cc: cmake@cmake.org Subject: Re: [CMake] Cross-compiling for z/OS -- linker question On Tuesday 05 August 2008, Phil Smith wrote: > Re the link command, thanks: > SET(CMAKE_C_LINK_EXECUTABLE "c:/progra~1/dignus/linkit.bat -o > ./ ") seems to be working much better! > > As for the ForceCompiler stuff, I think I understand what you're getting > at, but am reluctant to be quite that pure since it's likely to require a > bunch more tinkering. Not much :-) > For historical reasons, Dignus is really, really > unlikely to add any more compilers, and are equally unlikely to support any > other hardware platforms. Also for historical reasons, the various IBM > OSes for z are interoperable, so the OS doesn't seem relevant. Yes, so we only need a ZOS-Dignus-C.cmake and ZOS-Dignus-CXX.cmake (and a ZOS.cmake, which won't contain a lot). > I hate > everything I've just written -- I believe strongly in the purity of such > things, having been burned far too often by folks NOT bothering -- but find > myself unwilling to make the investment this time. If you want it to go into cmake cvs, it is necessary. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
