View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010225CMakeCMakepublic2010-02-01 16:462016-06-10 14:31
ReporterDaniel Richard G. 
Assigned ToBill Hoffman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010225: Cannot override CMAKE_EXE_LINKER_FLAGS_INIT with CMAKE_USER_MAKE_RULES_OVERRIDE + Intel compiler
DescriptionI make use of CMAKE_USER_MAKE_RULES_OVERRIDE to set various CMAKE_{C,CXX}_FLAGS*_INIT variables with custom flags. This normally works well.

I recently encountered Bug 10222 with the Intel compiler, and sought to work around it by setting my own custom value of CMAKE_EXE_LINKER_FLAGS_INIT with /INCREMENTAL:NO instead of the default /INCREMENTAL:YES. (CMAKE_{MODULE,SHARED}_LINKER_FLAGS_INIT also need to be set, as they are initialized with the value of the _EXE_ variable.)

Unfortunately, this does not work. The override file is loaded, but the compiler nonetheless sees the stock value of CMAKE_*_LINKER_FLAGS_INIT, which triggers the aforementioned bug. The correct value (/INCREMENTAL:NO) is present in the main CMakeCache.txt file, even---but if --debug-trycompile is given, then /INCREMENTAL:YES is clearly visible in the cache and build files for cmTryCompileExec.

This bug leaves me no recourse for working around Bug 10222 other than modifying the Windows-icl.cmake file directly. There seems to be no better way of getting that fatal /INCREMENTAL:YES option away from the compiler.
Additional InformationI am attaching a tarball of a lightly-modified Hello sample that can be used as a minimal test case for the bug.
TagsNo tags attached.
Attached Filesgz file icon Hello.tar.gz [^] (666 bytes) 2010-02-01 16:46
txt file icon trace.txt [^] (70,593 bytes) 2010-02-01 17:28 [Show Content]
txt file icon trace2.txt [^] (70,843 bytes) 2010-02-02 12:05 [Show Content]

 Relationships
related to 0010222closedBill Hoffman Default linker flags fail with Intel 9.0 C/C++ compiler (icl) 

  Notes
(0019417)
Bill Hoffman (manager)
2010-02-01 16:59

 Can you run with cmake --trace to see why the override is not working?
(0019419)
Daniel Richard G. (reporter)
2010-02-01 17:28

 I'm uploading a trace file produced from the modified sample.

Note that if you call message() in Windows-icl.cmake right when CMAKE_EXE_LINKER_FLAGS_INIT is set, you'll find that the variable is set twice, even though the trace doesn't reflect this.
(0019429)
Bill Hoffman (manager)
2010-02-02 08:33

 The order looks good. Did you run with an empty cache? That is an init variable only. Once used it gets cached, and after that it can not be changed.

Looking at your trace:

Windows-icl.cmake(74): SET(CMAKE_EXE_LINKER_FLAGS_INIT /STACK:10000000 /INCREMENTAL:YES )
CMakeOverride.txt(1): SET(CMAKE_EXE_LINKER_FLAGS_INIT /STACK:10000000 /INCREMENTAL:NO )
CMakeCommonLanguageInclude.cmake(19): SET(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS_INIT} $ENV{LDFLAGS} CACHE STRING Flags used by the linker. )

The order seems correct.
(0019435)
Daniel Richard G. (reporter)
2010-02-02 12:04

 This was with an empty cache, yes---but, again, the compiler was passed /INCREMENTAL:YES even though the cache contained the desired value of /INCREMENTAL:NO.

I'm attaching another trace file, but with one twist: Both places where the linker flags variable(s) are set (Windows-icl.cmake and CMakeOverride.txt) have been instrumented with a message() call. Grep for ">>" and you'll see something curious:

$ grep '>>' trace2.txt
C:/tmp/cmake-2.8.0-win32-x86/share/cmake-2.8/Modules/Platform/Windows-icl.cmake(75): message(>> Set CMAKE_EXE_LINKER_FLAGS_INIT to stock value )
>> Set CMAKE_EXE_LINKER_FLAGS_INIT to stock value
C:/work/Hello/CMakeOverride.txt(5): message(>> Set CMAKE_{EXE,MODULE,SHARED}_LINKER_FLAGS_INIT to custom value )
>> Set CMAKE_{EXE,MODULE,SHARED}_LINKER_FLAGS_INIT to custom value
>> Set CMAKE_EXE_LINKER_FLAGS_INIT to stock value

That last message is not covered by the trace, but comes right after a TRY_COMPILE() call, which suggests that it is from a separate invocation of CMake---which picks up the stock value in Windows-icl.cmake, but not the custom value I had set in my CMakeOverride.txt file.
(0019436)
Bill Hoffman (manager)
2010-02-02 12:12

 That must be the problem. Try_compile must not use the CMakeOverride.
(0019437)
Bill Hoffman (manager)
2010-02-02 12:13

 Let's focus on the other issue that caused this problem first. I would like to figure that out.
(0041652)
Kitware Robot (administrator)
2016-06-10 14:27

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2010-02-01 16:46 Daniel Richard G. New Issue
2010-02-01 16:46 Daniel Richard G. File Added: Hello.tar.gz
2010-02-01 16:59 Bill Hoffman Note Added: 0019417
2010-02-01 17:28 Daniel Richard G. Note Added: 0019419
2010-02-01 17:28 Daniel Richard G. File Added: trace.txt
2010-02-02 08:33 Bill Hoffman Note Added: 0019429
2010-02-02 08:33 Bill Hoffman Status new => assigned
2010-02-02 08:33 Bill Hoffman Assigned To => Bill Hoffman
2010-02-02 12:04 Daniel Richard G. Note Added: 0019435
2010-02-02 12:05 Daniel Richard G. File Added: trace2.txt
2010-02-02 12:12 Bill Hoffman Note Added: 0019436
2010-02-02 12:13 Bill Hoffman Note Added: 0019437
2010-02-04 09:00 Bill Hoffman Relationship added related to 0010222
2016-06-10 14:27 Kitware Robot Note Added: 0041652
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team