MantisBT - CMake
View Issue Details
0009906CMakeCMakepublic2009-11-16 12:252009-12-23 12:51
Emmanuel Blot 
Alex Neundorf 
normalmajoralways
closedno change required 
CMake-2-8 
 
0009906: CMake 2.8 applies OS X host information to all targets, ignoring cross-compilation use cases
When CMake 2.8 is used in cross-compilation projets, and run on an OS X host, it always attempts to apply the CMAKE_OSX_DEPLOYMENT_TARGET information as a default compiler option switch

This option switch should only be used for native compilation projects, i.e. host === target, as it breaks cross-compiler invocation.

On my machine, CMake 2.8 applies the "-mmacosx-version-min=10.6" option switch, which only exists for Apple's native version of GCC.
No tags attached.
related to 0009959closed David Cole new CMAKE_OSX_DEPLOYMENT_TARGET should set smarter if CMAKE_OSX_SYSROOT is defined 
Issue History
2009-11-16 12:25Emmanuel BlotNew Issue
2009-11-16 12:26Emmanuel BlotNote Added: 0018446
2009-11-16 13:06Bill HoffmanStatusnew => assigned
2009-11-16 13:06Bill HoffmanAssigned To => David Cole
2009-12-11 17:15David ColeNote Added: 0018831
2009-12-14 11:39David ColeRelationship addedrelated to 0009959
2009-12-14 13:09Emmanuel BlotNote Added: 0018861
2009-12-14 13:11Emmanuel BlotNote Added: 0018862
2009-12-14 13:13Emmanuel BlotNote Added: 0018863
2009-12-14 13:15Emmanuel BlotNote Added: 0018864
2009-12-14 13:59David ColeNote Added: 0018867
2009-12-14 14:56Alex NeundorfNote Added: 0018872
2009-12-14 18:00David ColeNote Added: 0018882
2009-12-14 18:00David ColeStatusassigned => resolved
2009-12-14 18:00David ColeResolutionopen => no change required
2009-12-14 18:26Emmanuel BlotNote Added: 0018884
2009-12-14 18:26Emmanuel BlotStatusresolved => feedback
2009-12-14 18:26Emmanuel BlotResolutionno change required => reopened
2009-12-14 18:34David ColeNote Added: 0018885
2009-12-14 18:34Emmanuel BlotNote Added: 0018886
2009-12-14 18:58Emmanuel BlotNote Added: 0018888
2009-12-14 19:03David ColeNote Added: 0018889
2009-12-14 19:03David ColeStatusfeedback => resolved
2009-12-14 19:03David ColeResolutionreopened => no change required
2009-12-15 16:41Alex NeundorfNote Added: 0018905
2009-12-15 16:41Alex NeundorfStatusresolved => feedback
2009-12-15 16:41Alex NeundorfResolutionno change required => reopened
2009-12-15 16:49David ColeStatusfeedback => assigned
2009-12-15 16:49David ColeAssigned ToDavid Cole => Alex Neundorf
2009-12-15 17:23Emmanuel BlotNote Added: 0018906
2009-12-23 12:51Alex NeundorfNote Added: 0018988
2009-12-23 12:51Alex NeundorfStatusassigned => closed
2009-12-23 12:51Alex NeundorfResolutionreopened => no change required

Notes
(0018446)
Emmanuel Blot   
2009-11-16 12:26   
Temporary workaround suggested by Bill Hoffman:

set CMAKE_OSX_DEPLOYMENT_TARGET to empty
(0018831)
David Cole   
2009-12-11 17:15   
Can you provide steps to reproduce this problem? Or a sample project and instructions on how to build it so that I can replicate the problem you are seeing?
(0018861)
Emmanuel Blot   
2009-12-14 13:09   
Top-level CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
IF (POLICY CMP0011)
   CMAKE_POLICY (SET CMP0011 NEW)
ENDIF (POLICY CMP0011)


# GCC tool suite required
use_arm_gcc()

PROJECT (npflasher)

# define subprojects
SET (subprojects
     main)

SET (ARCH "-mcpu=arm926ej-s -mno-thumb")
SET (GCC_WARN_DEFS "-Wall -Werror-implicit-function-declaration -Wstrict-prototypes")
SET (GCC_FEAT_DEFS "-fgnu89-inline -ffunction-sections -fdata-sections -fno-strict-aliasing")
SET (CMAKE_C_FLAGS "${ARCH} -std=gnu99 ${GCC_FEAT_DEFS} ${GCC_WARN_DEFS} -Os -fomit-frame-pointer")

ENABLE_LANGUAGE (ASM-ATT OPTIONAL)
SET (CMAKE_ASM-ATT_COMPILER ${xcc})
SET (CMAKE_ASM-ATT_COMPILE_OBJECT
     "<CMAKE_ASM-ATT_COMPILER> <FLAGS> -c -o <OBJECT> <SOURCE>")
SET (CMAKE_ASM-ATT_FLAGS "${ARCH} -Wall")
SET (CMAKE_ASM-ATT_FLAGS_DEBUG "-DDEBUG")
SET (CMAKE_ASM-ATT_FLAGS_RELEASE "-DNDEBUG")

SET (CMAKE_C_COMPILE_OBJECT
     "<CMAKE_C_COMPILER> <FLAGS> -o <OBJECT> -c <SOURCE>")
SET (CMAKE_C_LINK_EXECUTABLE
     "<CMAKE_C_COMPILER> <CMAKE_C_LINK_FLAGS> <OBJECTS> ${CRT0} -o <TARGET>")

# build all projects
FOREACH (project ${subprojects})
  ADD_SUBDIRECTORY (${project} ${project})
ENDFOREACH (project)

# fake install rule to all "install" target
INSTALL (CODE "MESSAGE(\"No installation required\")")
(0018862)
Emmanuel Blot   
2009-12-14 13:11   
Subproject CMakeLists.txt

SET (COMPONENT npflasher)

SET (CMAKE_EXECUTABLE_SUFFIX ".elf")
SET (CMAKE_C_LINK_FLAGS
     "-fmessage-length=0 -T${CMAKE_CURRENT_SOURCE_DIR}/target.ld -nostartfiles -g -Wl,--gc-sections -Wl,--Map -Wl,${COMPONENT}.map")

ADD_EXECUTABLE (${COMPONENT}
                src/command.c
                src/crt0.S
                src/...
                src/svnbldver.c)
(0018863)
Emmanuel Blot   
2009-12-14 13:13   
Note that for now, CMake 2.8 is not backward compatible with CMake 2.6, so we cannot build cross-compilation projects anymore. We can't use CMake 2.8 AFAICT.

Anyway, the above files should be enough to reproduce the issue.

HTH,
Manu
(0018864)
Emmanuel Blot   
2009-12-14 13:15   
I forgot to include the use_arm_gcc() macro:

IF (NOT XTOOLCHAIN)
  SET(XTOOLCHAIN "arm-eabi")
ENDIF (NOT XTOOLCHAIN)

MACRO (use_arm_gcc)
  INCLUDE (CMakeForceCompiler)
  FIND_PROGRAM (xcc ${XTOOLCHAIN}-gcc)
  FIND_PROGRAM (xar ${XTOOLCHAIN}-ar)
  FIND_PROGRAM (xld ${XTOOLCHAIN}-ld)
  CMAKE_FORCE_C_COMPILER (${xcc} GNU 4)
  CMAKE_FORCE_CXX_COMPILER (${xcc} GNU)
  SET (CMAKE_ASM-ATT_COMPILER ${xcc})
  SET (CMAKE_NOT_USING_CONFIG_FLAGS 1) # allow custom DEBUG/RELEASE flags
ENDMACRO (use_arm_gcc)
(0018867)
David Cole   
2009-12-14 13:59   
Thanks for all the notes you've attached. May I suggest that next time it might be easier to assemble it as a tar.gz file of a directory structure with all the files in it...?

I am not a big cross-compile guy myself, so it would really help me out if you could tell me exactly how to run cmake on this CMakeLists.txt file to produce the errors you're seeing.

Do I just run this sequence?
src $mkdir ../build
src $cd ../build
build $cmake ../src
build $make

Or do I need some sort of toolchain file and its associated compilers...?

I get other kinds of errors than what you are seeing (because I don't have all the source files you reference... command.c, crt0.S, ..., svnbldver.c ) with CMake 2.6, 2.8 or CVS HEAD...
(0018872)
Alex Neundorf   
2009-12-14 14:56   
I think you should use a toolchain file as described here: http://www.cmake.org/Wiki/CMake_Cross_Compiling [^]

As you do it now, cmake will start and try to determine the system, which will bring OSX/Darwin, and so it should load the Darwin-specific file.

Use a toolchain file, which sets CMAKE_SYSTEM_NAME to the name of your target system, this way the specific file will be loaded.

To make sure I'm understanding correctly, can you pleast attach the output of a cmake run in a clean build dir for such a project here ?

Alex
(0018882)
David Cole   
2009-12-14 18:00   
I'm resolving this issue as "no change required" assuming that Alex pointing you to the Wiki page on cross-compiling [ http://www.cmake.org/Wiki/CMake_Cross_Compiling [^] ] should work for your case.

The only way that CMake officially supports cross compiling is with a toolchain file as referenced on that Wiki page.

If you disagree, or come up with some other change you think is required in CMake to resolve this issue to your satisfaction, then please re-open the issue and attach further details as needed.

Thanks,
David Cole
(0018884)
Emmanuel Blot   
2009-12-14 18:26   
I'm not sure if it is worth to re-open this issue (you may want to close it again), but I don't see the proper way to comment your last comment w/o reopening the issue.

Will this "toolchain" file be backward compatible with CMake 2.6? Or should I add some directives so that CMake 2.6 and CMake 2.8 can both use the same script files?
(0018885)
David Cole   
2009-12-14 18:34   
As far as I know, you should be able to use the same toolchain file with CMake 2.6 and CMake 2.8. I will leave the issue open for now, and see if Alex adds any more comments.
(0018886)
Emmanuel Blot   
2009-12-14 18:34   
I'm not sure to understand how using a toolchain file will produce different results than the one I already use:

SET(CMAKE_SYSTEM_NAME eCos)
CMAKE_FORCE_C_COMPILER(arm-elf-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(arm-elf-g++ GNU)

what are the directive(s) that can make the difference?
(0018888)
Emmanuel Blot   
2009-12-14 18:58   
Got it: the key here is the directive CMAKE_SYSTEM_NAME
SET (CMAKE_SYSTEM_NAME none) seems to make it for OS-less projects.

It seems that CMake 2.8 requires it, while CMake 2.6 does not need it.

You may close this issue. Thanks for your help.
(0018889)
David Cole   
2009-12-14 19:03   
I'm resolving this issue (again!) as "no change required" assuming that Alex pointing you to the Wiki page on cross-compiling [ http://www.cmake.org/Wiki/CMake_Cross_Compiling [^] ] should work for your case.

The only way that CMake officially supports cross compiling is with a toolchain file as referenced on that Wiki page.

If you disagree, or come up with some other change you think is required in CMake to resolve this issue to your satisfaction, then please re-open the issue and attach further details as needed.

Thanks,
David Cole
(0018905)
Alex Neundorf   
2009-12-15 16:41   
> SET(CMAKE_SYSTEM_NAME eCos)
> CMAKE_FORCE_C_COMPILER(arm-elf-gcc GNU)
> CMAKE_FORCE_CXX_COMPILER(arm-elf-g++ GNU)

Where do you have that ?
In a toolchain file ?
This wasn't obvious from your other posts.
And the other code you posted is in your CMakeLists.txt ?

This would be wrong it seems.

Also, how does that go together with your comment that
> SET (CMAKE_SYSTEM_NAME none)
is required with cmake 2.8 if you set it to eCos ?

If you don't have any operating system, I would suggest you set this to "General", then there are some support files which will be loaded.

Alex
(0018906)
Emmanuel Blot   
2009-12-15 17:23   
>
I copied it in note:0018864, from the use_arm_gcc() that was copied in note: 0018861, with the exception of the "CMAKE_SYSTEM_NAME" directive.

Sorry, it was a bit complicated to provide the exact configuration files, because of confidentiality issues.
The environment we work on is as follow:
  Many hosts (Cygwin, Linux, Mac OS X)
  Two CPU targets (ARM7, ARM9)
  Several target applications (two w/o any OS, the other ones based on eCos)

We use a lot of CMake macros as most of the CMake configuration parameters are shared among all projects (eCos ones and OS-less ones). I would have had to post many CMakeLists.txt files to show the whole environment, so I tried to shrink them down into a couple of CMakeLists.txt snippets.

It seems that with the help of CMAKE_SYSTEM_NAME - assigned to "eCos" for eCos projects and to "generic" for OS-less projects - our CMakeLists.txt files work both with CMake 2.6 and CMake 2.8
(0018988)
Alex Neundorf   
2009-12-23 12:51   
Yes, that sounds good.
I'd still suggest to use "Generic" for the ones without OS.

Alex