4

CMakeLists.txt:

cmake_minimum_required(VERSION 3.14)

include(FetchContent)
FetchContent_Declare(vcpkg GIT_REPOSITORY https://github.com/microsoft/vcpkg/ GIT_TAG 2022.09.27)
FetchContent_MakeAvailable(vcpkg)
set(CMAKE_TOOLCHAIN_FILE "${vcpkg_SOURCE_DIR}/scripts/buildsystems/vcpkg.cmake" CACHE FILEPATH "")

project(MyProject)

set(CMAKE_CXX_STANDARD 20)

find_package(spdlog CONFIG REQUIRED)

add_executable(${CMAKE_PROJECT_NAME} src/main.cpp)
target_link_libraries(${CMAKE_PROJECT_NAME} PRIVATE spdlog::spdlog)

vcpkg.json:

{
    "name": "main",
    "version-string": "latest",
    "dependencies": [
        "spdlog"
    ]
}

It succesfully builds and runs for native target, but when I add -DVCPKG_TARGET_TRIPLET=wasm32-emscripten (and also I have all EMSDK enviroment variables correctly set) the build configuration fails:

CMake Error at cmake-build-release-wasm/_deps/vcpkg-src/scripts/buildsystems/vcpkg.cmake:829 (_find_package):
  Could not find a configuration file for package "spdlog" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

    C:/Users/kiv/Projects/MyProject/cmake-build-release-wasm/vcpkg_installed/wasm32-emscripten/share/spdlog/spdlogConfig.cmake, version: 1.10.0 (32bit)

Looking on the internet gives me that this error might be because of incompatible version of the library (e. g. trying to use system library when crosscompiling), but this is wrong in my case.

I've checked the archive cmake-build-release-wasm\vcpkg_installed\wasm32-emscripten\lib\libspdlog.a, unpacked spdlog.cpp.o and executed Linux file tool on it:

$ file spdlog.cpp.o
spdlog.cpp.o: WebAssembly (wasm) binary module version 0x1 (MVP)

So the library is definetely built for WASM target and it should be safe to use it. Is it possible somehow to force find_package pick it? I've tried specify "1.10.0 (32bit)" as a version argument for find_package, but it fails with invalid argument error. If I just specify "1.10.0" I got the same error about not accepted configuration.

UPD:

I've found the place where package compatibility is checked:

vcpkg_installed/wasm32-emscripten/share/spdlog/spdlogConfigVersion.cmake:

...
# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set, ignore it:
if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "4" STREQUAL "")
  return()
endif()

# check that the installed version has the same 32/64bit-ness as the one which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "4")
  math(EXPR installedBits "4 * 8")
  set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
  set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()

I've added message("${CMAKE_SIZEOF_VOID_P}") before``find_packageand CMake outputs "8" before fail. So it seems likeCMAKE_SIZEOF_VOID_P` set from host system instead of target.

kiv_apple
  • 491
  • 3
  • 13
  • I got the same problem (*also with vcpkg and that same triplet*) but with a different dependency(*s*). Googling for "vcpkg" and "CMAKE_SIZEOF_VOID_P" brought me to this [workaround/hack](https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtBuild.cmake?h=wip/cmake&id=0d177053b9406e2fb21802d23f2b2cdc0f974377#n3127) in Qt sources, where they just unset the value before finding a package and then set it back. I tried it out, and it works for me too, but I have 30+ dependencies in my project spread across different subprojects, so I hope there is a better/proper way (*which I haven't found yet*). – retif Feb 08 '23 at 15:32
  • Some more discoveries. As you pointed out, this condition originates in the version config, which is in most cases generated with [write_basic_package_version_file()](https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#command:write_basic_package_version_file), which adds this condition when `ARCH_INDEPENDENT` isn't set (*which almost never is set*). But anyway, that doesn't get us closer to a solution, as we certainly aren't going to patch every single port to add this argument. Also here's a related [bugreport](https://gitlab.kitware.com/cmake/cmake/-/issues/24375). – retif Feb 09 '23 at 14:49
  • Another discovery: even though `wasm32-emscripten` triplet does chainload the Emscripten toolchain, I still added it explicitly (`-DVCPKG_CHAINLOAD_TOOLCHAIN_FILE="${EMSDK}/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake"`) when running CMake, and then I didn't get these errors about non-compatible 32bit packages, as `CMAKE_SIZEOF_VOID_P` equaled `4`. Not sure what's wrong with the triplet file (*or whether what I did is a correct way to go or not*). – retif Feb 11 '23 at 18:45

0 Answers0