MantisBT - CMake
View Issue Details
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.
Steps To Reproduce
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.
Relationships
related to 0010222closed Bill Hoffman Default linker flags fail with Intel 9.0 C/C++ compiler (icl) 
Attached Filesgz Hello.tar.gz (666) 2010-02-01 16:46
https://public.kitware.com/Bug/file/2837/Hello.tar.gz
txt trace.txt (70,593) 2010-02-01 17:28
https://public.kitware.com/Bug/file/2838/trace.txt
txt trace2.txt (70,843) 2010-02-02 12:05
https://public.kitware.com/Bug/file/2842/trace2.txt
Issue History
Date ModifiedUsernameFieldChange
2010-02-01 16:46Daniel Richard G.New Issue
2010-02-01 16:46Daniel Richard G.File Added: Hello.tar.gz
2010-02-01 16:59Bill HoffmanNote Added: 0019417
2010-02-01 17:28Daniel Richard G.Note Added: 0019419
2010-02-01 17:28Daniel Richard G.File Added: trace.txt
2010-02-02 08:33Bill HoffmanNote Added: 0019429
2010-02-02 08:33Bill HoffmanStatusnew => assigned
2010-02-02 08:33Bill HoffmanAssigned To => Bill Hoffman
2010-02-02 12:04Daniel Richard G.Note Added: 0019435
2010-02-02 12:05Daniel Richard G.File Added: trace2.txt
2010-02-02 12:12Bill HoffmanNote Added: 0019436
2010-02-02 12:13Bill HoffmanNote Added: 0019437
2010-02-04 09:00Bill HoffmanRelationship addedrelated to 0010222
2016-06-10 14:27Kitware RobotNote Added: 0041652
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0019417)
Bill Hoffman   
2010-02-01 16:59   
Can you run with cmake --trace to see why the override is not working?
(0019419)
Daniel Richard G.   
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   
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.   
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   
2010-02-02 12:12   
That must be the problem. Try_compile must not use the CMakeOverride.
(0019437)
Bill Hoffman   
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   
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.