Vcpkg: Failed to install gflags

Created on 17 Aug 2017  ·  17Comments  ·  Source: microsoft/vcpkg

ENV:

  1. vcpkg version bd7cd7f56d5d9fdfeb1f57810a2ea77bf4d7e31a
  2. Windows 10 professional, simplified Chinese locale
  3. cmake: 3.9.1 c:/Program Files/CMake/
  4. git: 2.14.1.windows.1
  5. Installed VS

    • Microsoft Visual Studio Community 2017 15.2 (26430.16) Release

    • Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3

  6. I have successfully installed libevent:x86-windows and libevent:x86-windows, but failed to install gflags.

The output is :

D:\git\vcpkg>vcpkg install glog gflags
The following packages will be built and installed:
    gflags:x86-windows
    glog:x86-windows
Building package gflags:x86-windows...
-- CURRENT_INSTALLED_DIR=D:/git/vcpkg/installed/x86-windows
-- DOWNLOADS=D:/git/vcpkg/downloads
-- CURRENT_PACKAGES_DIR=D:/git/vcpkg/packages/gflags_x86-windows
-- CURRENT_BUILDTREES_DIR=D:/git/vcpkg/buildtrees/gflags
-- CURRENT_PORT_DIR=D:/git/vcpkg/ports/gflags/.
-- Using cached D:/git/vcpkg/downloads/gflags-gflags-v2.2.0.tar.gz
-- Testing integrity of cached file...
-- Testing integrity of cached file... OK
-- Extracting done
-- Applying patch D:/git/vcpkg/ports/gflags/fix-install.patch
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch D:/git/vcpkg/ports/gflags/fix-install.patch done
-- Applying patch D:/git/vcpkg/ports/gflags/fix-static-linking.patch
-- Applying patch failed. This is expected if this patch was previously applied.
-- Applying patch D:/git/vcpkg/ports/gflags/fix-static-linking.patch done
-- Configuring x86-windows-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:43 (message):
    Command failed: C:/Program Files/CMake/bin/cmake.exe;D:/git/vcpkg/buildtrees/gflags/src/gflags-2.2.0;-DGFLAGS_REGISTER_BUILD_DIR:BOOL=OFF;-DGFLAGS_REGISTER_INSTALL_PREFIX:BOOL=OFF;-DBUILD_gflags_nothreads_LIB:BOOL=OFF;-DBUILD_SHARED_LIBS=ON;-DVCPKG_TARGET_TRIPLET=x86-windows;-DCMAKE_CXX_FLAGS= /DWIN32 /D_WINDOWS /W3 /utf-8 /GR /EHsc /MP ;-DCMAKE_C_FLAGS= /DWIN32 /D_WINDOWS /W3 /utf-8 /MP ;-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON;-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON;-DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON;-DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE;-DCMAKE_VERBOSE_MAKEFILE=ON;-DVCPKG_APPLOCAL_DEPS=OFF;-DCMAKE_TOOLCHAIN_FILE=D:/git/vcpkg/scripts/buildsystems/vcpkg.cmake;-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON;-DCMAKE_CXX_FLAGS_RELEASE=/MD /O2 /Oi /Gy /DNDEBUG /Zi ;-DCMAKE_C_FLAGS_RELEASE=/MD /O2 /Oi /Gy /DNDEBUG /Zi ;-DCMAKE_SHARED_LINKER_FLAGS_RELEASE=/DEBUG /INCREMENTAL:NO /OPT:REF /OPT:ICF ;-DCMAKE_EXE_LINKER_FLAGS_RELEASE=/DEBUG /INCREMENTAL:NO /OPT:REF /OPT:ICF ;-G;Ninja;-DCMAKE_BUILD_TYPE=Release;-DCMAKE_INSTALL_PREFIX=D:/git/vcpkg/packages/gflags_x86-windows
    Working Directory: D:/git/vcpkg/buildtrees/gflags/x86-windows-rel
    See logs for more information:
      D:\git\vcpkg\buildtrees\gflags\config-x86-windows-rel-out.log
      D:\git\vcpkg\buildtrees\gflags\config-x86-windows-rel-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:170 (vcpkg_execute_required_process)
  ports/gflags/portfile.cmake:18 (vcpkg_configure_cmake)
  scripts/ports.cmake:72 (include)


Error: Building package gflags:x86-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: gflags:x86-windows
  Vcpkg version: 0.0.83-bd7cd7f56d5d9fdfeb1f57810a2ea77bf4d7e31a

Additionally, attach any relevant sections from the log files above.

And the content of D:\git\vcpkg\buildtrees\gflags\config-x86-windows-rel-err.log is :

CMake Error at C:/Program Files/CMake/share/cmake-3.9/Modules/CMakeTestCXXCompiler.cmake:44 (message):
  The C++ compiler "C:/Program Files (x86)/Microsoft Visual
  Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX64/x86/cl.exe" is
  not able to compile a simple test program.

  It fails with the following output:

   Change Dir: D:/git/vcpkg/buildtrees/gflags/x86-windows-rel/CMakeFiles/CMakeTmp



  Run Build
  Command:"D:/git/vcpkg/downloads/tools/ninja/ninja-1.7.2/ninja.exe"
  "cmTC_81c7a"

  ninja: error: build.ninja:30: loading 'rules.ninja':
  系统找不到指定的文件。




  include rules.ninja


                     ^ near here





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:94 (project)



vcpkg-bug

Most helpful comment

See CMake MR 1179 for the fix. It will be in 3.9.2. The use of UTF-8 console i/o proposed in #1682 is consistent with the explanation in the CMake MR, but should not be necessary once it lands.

All 17 comments

rollback cmake to 3.8.2, cmake 3.9.x create ninja project failed

Thanks @fcharlie
When I rollback cmake to 3.8.2, vcpkg will automatically try to download and install cmake 3.9.1 itself.

@zieckey rename cmake-3.8.2-win32-x86 to cmake-3.9.1-win32-x86

I used cmake-3.8.2-win64-x64.msi to install cmake. I cannot rename it to cmake-3.9.1-win64-x64.msi

@zieckey Please download https://cmake.org/files/v3.8/cmake-3.8.2-win32-x86.zip, unpack to vcpkg root downloads after rename cmake-3.8.2-win32-x86 to cmake-3.9.1-win32-x86

aslo your can use msiexec unpack cmake-3.8.2-win64-x64.msi

Update: You can chcp 65001

if you comment out the prefer_ninja in the gflags port file, does it compile?

As suggested by @fcharlie, chcp 65001 in the console you're running Vcpkg from is the best way to work around this issue.

Unfortunately, cmake+ninja has some trouble with non-English codepages on Windows, though I'm not sure where in the stack the true problem lies. We should probably fix this in the tool itself by setting the codepage before performing any build.

@ras0219-msft Ninja run on Windows Codepage 936 is success, but cmake 3.9 invoke ninja is failed !

cmake 3.8 is ok. cmake 3.9.x is failed

But use chcp 65001 mybe cause some old programs to fail to output properly

https://github.com/fstudio/clangbuilder/blob/908c21f7d179a17d05469c48395fcb92f2f32e46/bin/ClangbuilderTarget.ps1#L239

My Clangbuilder PS Function (Start-Process convert encoding, Start-Process -wait will wait Job Process, so I use .Net System.Diagnostics.Process )

Function ClangNinjaGenerator{
    param(
        [String]$ClangExe,
        [String]$BuildDir
    )
    $env:CC=$ClangExe
    $env:CXX=$ClangExe
    Write-Host "Build llvm, Use: CC=$env:CC CXX=$env:CXX"
    Set-Workdir $BuildDir
    $Arguments=Get-ClangArgument
    $oe=[Console]::OutputEncoding
    [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 ### Ninja need UTF8
    $exitcode = ProcessExec  -FilePath "cmake.exe" -Arguments $Arguments
    if ($exitcode -ne 0) {
        Write-Error "CMake exit: $exitcode"
        return 1
    }
    [Console]::OutputEncoding=$oe
    $PN = & Parallel
    $exitcode = ProcessExec -FilePath "ninja.exe" -Arguments "all -j $PN"
    return $exitcode
}
Function ProcessExec {
    param(
        [string]$FilePath,
        [string]$Arguments,
        [string]$WorkingDirectory
    )
    $ProcessInfo = New-Object System.Diagnostics.ProcessStartInfo 
    $ProcessInfo.FileName = $FilePath
    Write-Host "$FilePath $Arguments $PWD"
    if ($WorkingDirectory.Length -eq 0) {
        $ProcessInfo.WorkingDirectory = $PWD
    }
    else {
        $ProcessInfo.WorkingDirectory = $WorkingDirectory
    }
    $ProcessInfo.Arguments = $Arguments
    $ProcessInfo.UseShellExecute = $false ## use createprocess not shellexecute
    $Process = New-Object System.Diagnostics.Process 
    $Process.StartInfo = $ProcessInfo 
    if ($Process.Start() -eq $false) {
        return -1
    }
    $Process.WaitForExit()
    return $Process.ExitCode
}

@fcharlie I follow your advice, it works. Thanks.

@zieckey @fcharlie please test #1682

@Mixaill I test it.

See CMake MR 1179 for the fix. It will be in 3.9.2. The use of UTF-8 console i/o proposed in #1682 is consistent with the explanation in the CMake MR, but should not be necessary once it lands.

@bradking Thanks, @ras0219-msft Now ,Your need create a patch to fix CMakeDetermineCompilerId.cmake, not need rebuild cmake, or wait cmake 3.9.2.

https://gitlab.kitware.com/brad.king/cmake/commit/de9840d1b89481132ee128715506f6aee9d0277c

I think in parallel with the upstream CMake fix, we should look at just _always_ using chcp 65001 internally. This will further improve build consistency between machines, ensuring that everyone is able to reproduce any errors easily.

@ras0219-msft This will also fix various display problems, such as non-English text corruption (for example, in private ports).

Please report if the latest master fixes things for you.

Was this page helpful?
0 / 5 - 0 ratings