MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009992CMakeCMakepublic2009-12-02 12:002010-11-09 22:57
ReporterRyan Pavlik 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0009992: Install dir on Win64 always starts with c:/program files (x86)/ regardless of architecture of build
DescriptionThe issue here is that CMAKE_INSTALL_PREFIX seems to be using the %ProgramFiles% environment variable to set this, which is problematic: on win64 machines, the WOW64 subsystem transparently changes this environment variable to point to the program files dir that matches the architecture of the running application (in this case, CMake-Gui though I presume cmake itself has the same issue). When building a 64-bit application (using a 64-bit generator), this results in an incorrect install prefix and potentially broken/weird installers.

Here's the logic and comments I wrote in a CMake module related to this that describes the solution - _PROGFILESDIR at the end of this code contains the correct "prefix" for the install prefix:


    # caution - ENV{ProgramFiles} on Win64 is adjusted to point to the arch of the running executable
    # which, since CMake is 32-bit on Windows as I write this, will always be = $ENV{ProgramFiles(x86)}
    # so we only use this environment variable if we figure out we're on win32
    file(TO_CMAKE_PATH "$ENV{ProgramFiles}" _PROG_FILES) # 32-bit dir on win32, useless to us on win64
    file(TO_CMAKE_PATH "$ENV{ProgramFiles(x86)}" _PROG_FILES_X86) # 32-bit dir: only set on win64
    file(TO_CMAKE_PATH "$ENV{ProgramW6432}" _PROG_FILES_W6432) # 64-bit dir: only set on win64
    
    if(CMAKE_SIZEOF_VOID_P MATCHES "8")
        # 64-bit build on win64
        set(_PROGFILESDIR "${_PROG_FILES_W6432}")
    else()
        if(_PROG_FILES_W6432)
            # 32-bit build on win64
            set(_PROGFILESDIR "${_PROG_FILES_X86}")
        else()
            # 32-bit build on win32
            set(_PROGFILESDIR "${_PROG_FILES}")
        endif()
    endif()
Steps To Reproduce
Additional InformationThis bug also exists in CMake 2.6.
TagsNo tags attached.
Relationships
related to 0006363closed David Cole CMake 2.4.8 x64 Windows build from sources installs in 32bit directory C:\Program Files (x86)\CMake 
Attached Fileszip 20100115-install-prefix.zip (3,066) 2010-01-15 11:01
https://public.kitware.com/Bug/file/2773/20100115-install-prefix.zip
Issue History
Date ModifiedUsernameFieldChange
2009-12-02 12:00Ryan PavlikNew Issue
2009-12-02 12:08Bill HoffmanStatusnew => assigned
2009-12-02 12:08Bill HoffmanAssigned To => David Cole
2010-01-15 11:01Ryan PavlikFile Added: 20100115-install-prefix.zip
2010-01-15 11:02Ryan PavlikNote Added: 0019150
2010-04-19 12:04David ColeRelationship addedrelated to 0006363
2010-04-19 13:00Ryan PavlikNote Added: 0020256
2010-08-25 07:35David ColeNote Added: 0021942
2010-08-25 08:55Rolf Eike BeerNote Added: 0021949
2010-08-25 12:57David ColeNote Added: 0021958
2010-08-25 13:35Rolf Eike BeerNote Added: 0021960
2010-08-31 17:57David ColeTarget Version => CMake 2.8.3
2010-09-09 12:38David ColeNote Added: 0022163
2010-09-09 12:38David ColeStatusassigned => resolved
2010-09-09 12:38David ColeResolutionopen => fixed
2010-10-06 14:15David ColeFixed in Version => CMake 2.8.3
2010-11-09 22:57Philip LowmanStatusresolved => closed

Notes
(0019150)
Ryan Pavlik   
2010-01-15 11:02   
The file I attached is a patch series that should fix this bug (untested right now, but based on the tested code above), as well as another patch that applies a cleaner style to the file modified. ( CMakeGenericSystem.cmake )
(0020256)
Ryan Pavlik   
2010-04-19 13:00   
I have tested this patch extensively for some time now, and it work as advertised. Seems safe to apply.
(0021942)
David Cole   
2010-08-25 07:35   
We cannot accept the attached patch as is because CMAKE_SIZEOF_VOID_P is not correctly set on every call to CMakeGenericSystem.cmake. That file is included *before* CMAKE_SIZEOF_VOID_P has been computed, and any information cached in that state will not be accurate.

Needs more work.
(0021949)
Rolf Eike Beer   
2010-08-25 08:55   
This could fixed properly once 7866 and 10037 are solved I think: they are all about proper identification of a Win64 build.
(0021958)
David Cole   
2010-08-25 12:57   
The problem is that the only "proper identification of a Win64 build" possible in CMake is:
- to wait until after the CXX language has been enabled and test CMAKE_SIZEOF_VOID_P

The "solution" to 7866 and 10037 are both related to "what is the build of cmake that is currently running", *not* what is being built in the currently configuring project.

In this case, we need to know if the executables built for the currently configuring project are targeting Win64 or not, and we need to know that before setting the default value of CMAKE_INSTALL_PREFIX.

Hopefully, there's a solution here simply by delaying setting the value of CMAKE_INSTALL_PREFIX until we have sufficient information, but it's been a long time since I dug into the details, so this will take a little bit of effort to get right.
(0021960)
Rolf Eike Beer   
2010-08-25 13:35   
The reference to 10037 was bogus I think, that wasn't the bug I had in mind and I only looked on the tagline.

Well, 7866 was meant as "what am I building" and that was also the direction of the patch that was there. And that is basically also the point here: what am I building.

I have absolutely no clue about how Windows on Itanium looks like, but that is a platform with sizeof(void*)==8 too.
(0022163)
David Cole   
2010-09-09 12:38   
Fixed in CMake 'next' branch by this commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f98dac486726c67681ea51a57e19518d7119b1b [^]

Should make it into the 2.8.3 release.

Note: this is significantly different than the patches attached to this bug. Thanks for the effort, Ryan, but the tests we can do at the time CMakeGenericSystem is included are limited. The code I've added here makes a best-guess effort at determining the architecture of stuff that's going to be built.... But these are still only educated guesses... This code can be fooled. In cases where it is fooled, it is necessary to ask the end users to set CMAKE_INSTALL_PREFIX appropriately.