View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009906CMakeCMakepublic2009-11-16 12:252009-12-23 12:51
ReporterEmmanuel Blot 
Assigned ToAlex Neundorf 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0009906: CMake 2.8 applies OS X host information to all targets, ignoring cross-compilation use cases
DescriptionWhen 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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0009959closedDavid Cole new CMAKE_OSX_DEPLOYMENT_TARGET should set smarter if CMAKE_OSX_SYSROOT is defined 

  Notes
(0018446)
Emmanuel Blot (reporter)
2009-11-16 12:26

Temporary workaround suggested by Bill Hoffman:

set CMAKE_OSX_DEPLOYMENT_TARGET to empty
(0018831)
David Cole (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (developer)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (manager)
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 (developer)
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 (reporter)
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 (developer)
2009-12-23 12:51

Yes, that sounds good.
I'd still suggest to use "Generic" for the ones without OS.

Alex

 Issue History
Date Modified Username Field Change
2009-11-16 12:25 Emmanuel Blot New Issue
2009-11-16 12:26 Emmanuel Blot Note Added: 0018446
2009-11-16 13:06 Bill Hoffman Status new => assigned
2009-11-16 13:06 Bill Hoffman Assigned To => David Cole
2009-12-11 17:15 David Cole Note Added: 0018831
2009-12-14 11:39 David Cole Relationship added related to 0009959
2009-12-14 13:09 Emmanuel Blot Note Added: 0018861
2009-12-14 13:11 Emmanuel Blot Note Added: 0018862
2009-12-14 13:13 Emmanuel Blot Note Added: 0018863
2009-12-14 13:15 Emmanuel Blot Note Added: 0018864
2009-12-14 13:59 David Cole Note Added: 0018867
2009-12-14 14:56 Alex Neundorf Note Added: 0018872
2009-12-14 18:00 David Cole Note Added: 0018882
2009-12-14 18:00 David Cole Status assigned => resolved
2009-12-14 18:00 David Cole Resolution open => no change required
2009-12-14 18:26 Emmanuel Blot Note Added: 0018884
2009-12-14 18:26 Emmanuel Blot Status resolved => feedback
2009-12-14 18:26 Emmanuel Blot Resolution no change required => reopened
2009-12-14 18:34 David Cole Note Added: 0018885
2009-12-14 18:34 Emmanuel Blot Note Added: 0018886
2009-12-14 18:58 Emmanuel Blot Note Added: 0018888
2009-12-14 19:03 David Cole Note Added: 0018889
2009-12-14 19:03 David Cole Status feedback => resolved
2009-12-14 19:03 David Cole Resolution reopened => no change required
2009-12-15 16:41 Alex Neundorf Note Added: 0018905
2009-12-15 16:41 Alex Neundorf Status resolved => feedback
2009-12-15 16:41 Alex Neundorf Resolution no change required => reopened
2009-12-15 16:49 David Cole Status feedback => assigned
2009-12-15 16:49 David Cole Assigned To David Cole => Alex Neundorf
2009-12-15 17:23 Emmanuel Blot Note Added: 0018906
2009-12-23 12:51 Alex Neundorf Note Added: 0018988
2009-12-23 12:51 Alex Neundorf Status assigned => closed
2009-12-23 12:51 Alex Neundorf Resolution reopened => no change required


Copyright © 2000 - 2018 MantisBT Team