cmakevcpkgmupdf

Static linking error with vcpkg and libmupdf


I would like to use the libmupdf package provided by vcpkg. I installed it using the command vcpkg install libmupdf, while I'm used to get a find_package(...) & target_link_libraries(...) at the end of package installation, this time, I did not get anything on how to use the library.

Still, I ran vcpkg integrate install and tried to compile my projet but it obviously did not work.

I tried to manually include the library target_link_libraries(${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}/vcpkg/packages/libmupdf_x64-windows-static/lib/libmupdf.lib") but got plenty of LNK unresolved external symbol error because the library is missing his own dependencies(font, noto..).

libmupdf.lib has been built has a static library(triple x64-windows-static, the only triplet availaible btw) so I was a bit suprised that those were not included inside the .lib. After doing some research on stackoverflow, it looks like the dependencies are built alongside a file called libthirdparty.lib but I was not able to find it. Please note that Visual Studio is set to link with static runtime library(C/C++ > Code Genereation > Runtime Library > Multi-threaded(/MT).

I did tried to build mupdf without relying on vcpkg but got the same issue. Mupdf package is availaible here.

Thank you for your help,

EDIT :

I'm using vcpkg in manifest mode :

{
  "dependencies": [
        "wxwidgets",
        "curl",
        "nlohmann-json",
        "libmupdf"
  ],
  "builtin-baseline": "1a66c32c6f90c2f646529975c3c076ed3dbdae0c",
  "overrides": [
    {
        "name": "wxwidgets",
        "version": "3.2.6"
    },
    {
        "name": "curl",
        "version": "8.11.1"
    },
    {
        "name": "nlohmann-json",
        "version": "3.11.3#1"
    },
    {
        "name": "libmupdf",
        "version": "1.24.11"
    }
  ]
}

Here is my Cmake file :

cmake_minimum_required(VERSION 3.20)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_TOOLCHAIN_FILE "${CMAKE_CURRENT_SOURCE_DIR}/vcpkg/scripts/buildsystems/vcpkg.cmake")
set(VCPKG_TARGET_TRIPLET x64-windows-static)
project(FOO)
find_package(wxWidgets REQUIRED core base)
find_package(CURL REQUIRED)
find_package(nlohmann_json CONFIG REQUIRED)
include(${wxWidgets_USE_FILE})
add_executable(${PROJECT_NAME} WIN32
    ... all my .cpp
)
target_include_directories(${PROJECT_NAME} PRIVATE "inc/")
target_link_libraries(${PROJECT_NAME} PRIVATE ${wxWidgets_LIBRARIES})
target_link_libraries(${PROJECT_NAME} PRIVATE CURL::libcurl)
target_link_libraries(${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}/build/vcpkg_installed/x64-windows-static/lib/libmupdf.lib")
target_link_libraries(${PROJECT_NAME} PRIVATE nlohmann_json::nlohmann_json)

A sample of linking errors I got :

1>libmupdf.lib(xml.c.obj) : error LNK2019: unresolved external symbol gumbo_normalized_tagname referenced in function xml_from_gumbo
1>libmupdf.lib(xml.c.obj) : error LNK2019: unresolved external symbol gumbo_parse_with_options referenced in function fz_parse_xml_from_html5
1>libmupdf.lib(xml.c.obj) : error LNK2019: unresolved external symbol gumbo_destroy_output referenced in function fz_parse_xml_from_html5
1>libmupdf.lib(pdf-font-add.c.obj) : error LNK2019: unresolved external symbol FT_Get_Postscript_Name referenced in function pdf_add_descendant_cid_font
1>libmupdf.lib(pdf-font-add.c.obj) : error LNK2019: unresolved external symbol FT_Get_Font_Format referenced in function ft_font_file_kind
1>libmupdf.lib(pdf-font.c.obj) : error LNK2001: unresolved external symbol FT_Get_Font_Format
1>libmupdf.lib(pdf-font.c.obj) : error LNK2019: unresolved external symbol FT_Select_Charmap referenced in function load_cid_font
1>libmupdf.lib(pdf-font.c.obj) : error LNK2019: unresolved external symbol FT_Set_Charmap referenced in function pdf_load_simple_font
1>libmupdf.lib(pdf-font.c.obj) : error LNK2019: unresolved external symbol FT_Get_CMap_Format referenced in function select_truetype_cmap

Solution

  • As it turned out, vcpkg installs libmupdf without taking care of dependencies, a pull request should have fixed the issue but wasn't merged. Linking must be done manually(find_library(...)) for now.