Building pangomm in Manifest mode

[johne53]

I've made several attempts at building pangomm (and its dependencies) in manifest mode at an earlier revision. I've tried earlier versions of its main dependencies (pango/cairo/cairomm/glib/glibmm) but no matter which set of earlier overrides I choose, everything builds fine except for pangomm which consistently fails with this output:-

error: building pangomm:x64-windows failed with: BUILD_FAILED
See https://learn.microsoft.com/vcpkg/troubleshoot/build-failures?WT.mc_id=vcpkg_inproduct_cli for more information.
Elapsed time to handle pangomm:x64-windows: 1.3 min
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+pangomm

My (current) version of vcpkg.json looks like this, although I've tried lots of variations:-

{
  "$comment": "baseline value is the latest commit in vcpkg repo as of 14.03.2026",
  "builtin-baseline": "aa40adda5352e87655b8583cfb2451d5e9e276fd",
  "dependencies": [
    "pangomm",
    "cairomm",
    "glibmm",
    "pango",
    {
      "name": "cairo",
      "features": [
        "gobject"
      ]
    },
    "fontconfig",
    "freetype",
    "fribidi",
    {
      "name": "gettext",
      "host": true,
      "default-features": false,
      "features": [
        "tools"
      ]
    },
    "gettext-libintl",
    "glib",
    {
      "name": "glib",
      "host": true
    },
    "harfbuzz",
    {
      "name": "harfbuzz",
      "features": [
        "coretext"
      ],
      "platform": "osx"
    },
    {
      "name": "vcpkg-tool-meson",
      "host": true
    }
  ],
  "overrides": [
    {
      "name": "pango",
      "version": "1.48.4#1"
    },
    {
      "name": "pangomm",
      "version": "2.48.1#0"
    }
  ]
}

If I remove the overrides section (i.e. I build everything at their most recent versions) everything builds fine but I can't find any combination of earlier revisions where pangomm will build successfully.

Looking at buildtrees/pangomm/config-x64-windows-dbg-out.log shows me an error referring to python:-

WARNING: Recommend using either -Dbuildtype or -Doptimization + -Ddebug. Using both is redundant since they override each other. See: https://mesonbuild.com/Builtin-options.html#build-type-options
The Meson build system
Version: 0.58.1
Source dir: D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-710125c77b.clean
Build dir: D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\x64-windows-dbg
Build type: native build
Project name: pangomm
Project version: 2.48.1
C++ compiler for the host machine: G:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe -DWIN32 -D_WINDOWS -utf-8 -GR -EHsc -MP -MDd -Z7 -Ob0 -Od -RTC1 (msvc 19.44.35227 "Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35227 for x64")
C++ linker for the host machine: G:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/link.exe link 14.44.35227.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (D:/vcpkg-stuff/gnu-windows/src/vcpkg/downloads/tools/python/python-3.14.2-x64-1/python.exe)

..\src\pangomm-2-710125c77b.clean\meson.build:47:0: ERROR: <ExternalProgram 'python3' -> ['D:/vcpkg-stuff/gnu-windows/src/vcpkg/downloads/tools/python/python-3.14.2-x64-1/python.exe']> is not a valid python or it is missing setuptools

A full log can be found at D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\x64-windows-dbg\meson-logs\meson-log.txt

So can anyone show me how I'd need to modify vcpkg.json to make this work? Or do I need to update python maybe? If there's an issue with python it's strange that vcpkg will build the most recent pangomm but not any earlier version

[johne53]

I discovered 2 more things which might be relevant...

1. If I set my requested version to 2.777.1 I see this output (as expected):-
   error: no version database entry for pangomm at 2.777.1.

Available versions:
  2.56.1#1
  2.56.1
  2.50.1#3
  2.50.1#2
  2.50.1#1
  2.50.1
  2.50.0#2
  2.50.0#1
  2.50.0
  2.48.1#1
  2.48.1
  2.48.0
  2.40.1#4
  2.40.1-3
  2.40.1-2
  2.40.1-1
  2.40.1

However, that list doesn't correspond to the list at https://vcpkg.link/ports/pangomm/versions

It's only a minor difference but my printout doesn't contain any entries with #0 at the end. I'd been using the internet numbers so might that be the problem?

2. Up to now I haven't been able to build anything prior to version 2.50.1#1. And when a build fails I usually (but not always) see this output quite early in the build process:-

CMake Warning at scripts/cmake/vcpkg_fail_port_install.cmake:2 (message):
  vcpkg_fail_port_install has been removed and all values should be moved by
  adding `supports` field to manifest file or directly adding `pangomm:=fail`
  to _scripts/ci.baseline.txt_.

  Please remove `vcpkg_fail_port_install(...)`.

Might that be relevant somehow?

[Aleksandr Kovalko (gistrec)]

The warning is probably the key clue here.

With overrides, vcpkg checks out the port files for the historical package version, but the CMake helper scripts under scripts/cmake/vcpkg_*.cmake come from your currently installed vcpkg checkout. So an old pangomm port can end up calling helper macros that no longer exist in the current vcpkg scripts.

In this case, vcpkg_fail_port_install appears to be that mismatch: the old 2.48.1 port expects it, but your current vcpkg install no longer provides it. That would explain why the build fails before getting to a normal package/build issue.

The simplest fix is probably to bump the override to a newer pangomm version that matches the current helper API, for example 2.50.1#3 or 2.56.1.

If you specifically need 2.48.1, then you likely need to use a vcpkg checkout from around the same era as that port version, or pin a custom registry/baseline so the port files and helper scripts are from a compatible point in vcpkg history.

About #0: I would not treat that as the problem. vcpkg often omits #0 in CLI output and only shows non-zero port versions like #1, #2, etc. So 2.48.1 and 2.48.1#0 are effectively the same port-version notation.

[johne53]

Hi Aleksandr Kovalko (@gistrec) I managed to get a bit further with this. I'm now building an earlier version (after switching to builtin-baseline "a9b27ed5dffbf70b135eddb0c4729f3ca87f106c" like you described in the other thread yesterday) and I can now build tons of stuff from earlier versions but pangomm consistently fails and I see this message:-

    Working Directory: D:/vcpkg-stuff/gnu-windows/src/vcpkg/buildtrees/pangomm/x64-windows-rel
    Error code: 1
    See logs for more information:
      D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\build-x64-windows-rel-out.log

If I then look at that log file the actual error is this:-

2>pangomm.def : error LNK2001: unresolved external symbol
Avx2WmemEnabledWeakValue [D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-bb0817eca2.clean\MSVC_Net2013\pangomm.vcxproj]
     2>D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-bb0817eca2.clean\MSVC_Net2013\Release\x64\bin\pangomm.lib : fatal error LNK1120: 1 unresolved externals [D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-bb0817eca2.clean\MSVC_Net2013\pangomm.vcxproj]
     2>Done Building Project "D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-bb0817eca2.clean\MSVC_Net2013\pangomm.vcxproj" (default targets) -- FAILED.
     1>Done Building Project "D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\pangomm\src\pangomm-2-bb0817eca2.clean\MSVC_Net2013\pangomm.sln" (pangomm target(s)) -- FAILED.

I tried manually editing pangomm.def to remove all references to Avx2WmemEnabledWeakValue but next time I tried another build, pangomm.def just got regenerated.

Can you think of anything else I could try? I've tried adding various overrides for pangomm but they all give me the same error.

[Edit....] A bit more info. I searched through all the source files and patch files here and the word Avx2WmemEnabledWeakValue isn't in any of them so it's a bit strange that it ends up in pangomm.def. I looked on Google and apparently this can sometimes happen because of bugs in gendef.cc so I renamed pangomm's version and replaced it with a different version. But unfortunately, gendef.cc also gets recreated at build time so not much help really.

[Edit 2...] An idea just occurred to me. Is there a script somewhere that I could edit to prevent gendef.exe from getting run during a pangomm build? I'm just curious what would happen if I could remove Avx2WmemEnabledWeakValue from pangomm.def and then run a build without pangomm.def getting recreated.

[johne53]

" Is there a script somewhere that I could edit to prevent gendef.exe from getting run during a pangomm build? I'm just curious what would happen if I could remove Avx2WmemEnabledWeakValue from pangomm.def and then run a build without pangomm.def getting recreated. "

After taking a closer look I think all the source files / tools etc get extracted from an archive file prior to the build starting, which explains why any edits keep getting overwritten. So is there a way to stop that temporarily? i.e. say to vcpkg "don't extract anything from the zip file on this occasion. Just use the already existing files" ?

Apparently --editable can do this for Classic mode but is there anything similar for Manifest mode?