View Issue Details [ Jump to Notes ] [ Print ]
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()
Additional InformationThis bug also exists in CMake 2.6.
TagsNo tags attached.
Attached Fileszip file icon 20100115-install-prefix.zip [^] (3,066 bytes) 2010-01-15 11:01

 Relationships
related to 0006363closedDavid Cole CMake 2.4.8 x64 Windows build from sources installs in 32bit directory C:\Program Files (x86)\CMake 

  Notes
(0019150)
Ryan Pavlik (reporter)
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 (reporter)
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 (manager)
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 (developer)
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 (manager)
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 (developer)
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 (manager)
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.

 Issue History
Date Modified Username Field Change
2009-12-02 12:00 Ryan Pavlik New Issue
2009-12-02 12:08 Bill Hoffman Status new => assigned
2009-12-02 12:08 Bill Hoffman Assigned To => David Cole
2010-01-15 11:01 Ryan Pavlik File Added: 20100115-install-prefix.zip
2010-01-15 11:02 Ryan Pavlik Note Added: 0019150
2010-04-19 12:04 David Cole Relationship added related to 0006363
2010-04-19 13:00 Ryan Pavlik Note Added: 0020256
2010-08-25 07:35 David Cole Note Added: 0021942
2010-08-25 08:55 Rolf Eike Beer Note Added: 0021949
2010-08-25 12:57 David Cole Note Added: 0021958
2010-08-25 13:35 Rolf Eike Beer Note Added: 0021960
2010-08-31 17:57 David Cole Target Version => CMake 2.8.3
2010-09-09 12:38 David Cole Note Added: 0022163
2010-09-09 12:38 David Cole Status assigned => resolved
2010-09-09 12:38 David Cole Resolution open => fixed
2010-10-06 14:15 David Cole Fixed in Version => CMake 2.8.3
2010-11-09 22:57 Philip Lowman Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team