Building glib at version 2.78.1

[johne53]

I downloaded vcpkg a month or two ago and I've been experimenting with it on & off but I haven't yet used it for anything serious. In the past I've managed to build glib (in classic mode) which built version 2.86.4 (presumably the latest version?)

So this morning I thought I'd try building an earlier version (2.78.1) in manifest mode and I followed various instructions that people here helped me with. In fact I could post the contents of vcpkg.json and vcpkg-configuration.json here if needed.

Anyway, attempting vcpkg install --dry-run lists about half a dozen dependencies needed and then confirms it'll build glib at version 2.78.1 but whereas 2.86.4 built fine, 2.78.1 builds all the dependencies okay but when it comes to build glib, the process starts off normally but within a minute or so I see this output:-

CMake Warning at scripts/ports.cmake:182 (message):
Unexpected UNKNOWN_READ_ACCESS on variable APPLE in script mode.

This variable name insufficiently expresses whether it refers to the target
system or to the host system. Use a prefixed variable instead.

• Variables providing information about the host:

  CMAKE_HOST_
  VCPKG_HOST_IS_

• Variables providing information about the target:

  VCPKG_TARGET_IS_
  VCPKG_DETECTED_ (using vcpkg_cmake_get_vars)

Call Stack (most recent call first):
C:/Users/JohnE/AppData/Local/vcpkg/registries/git-trees/6c91a4d4382d4d271d13397214c536389fd4a122/portfile.cmake:2147483647 (z_vcpkg_warn_ambiguous_system_variables)
C:/Users/JohnE/AppData/Local/vcpkg/registries/git-trees/6c91a4d4382d4d271d13397214c536389fd4a122/portfile.cmake:15 (if)
scripts/ports.cmake:206 (include)

-- Using cached msys2-mingw-w64-x86_64-pkgconf-1~2.5.1-1-any.pkg.tar.zst
-- Using cached msys2-msys2-runtime-3.6.5-1-x86_64.pkg.tar.zst
-- Using msys root at D:/vcpkg-stuff/gnu-windows/src/vcpkg/downloads/tools/msys2/3e71d1f8e22ab23f
-- Configuring x64-windows-dbg
-- Getting CMake variables for x64-windows
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:127 (message):
Command failed: D:\vcpkg-stuff\gnu-windows\src\vcpkg\downloads\tools\ninja-1.13.2-windows\ninja.exe -v
Working Directory: D:/vcpkg-stuff/gnu-windows/src/vcpkg/buildtrees/glib/x64-windows-rel/vcpkg-parallel-configure
Error code: 1
See logs for more information:
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-dbg-CMakeCache.txt.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-rel-CMakeCache.txt.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-dbg-CMakeConfigureLog.yaml.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-rel-CMakeConfigureLog.yaml.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-out.log

Call Stack (most recent call first):
ArdourSupportJE/vcpkg_installed/x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:269 (vcpkg_execute_required_process)
ArdourSupportJE/vcpkg_installed/x64-windows/share/vcpkg-cmake-get-vars/vcpkg_cmake_get_vars.cmake:20 (vcpkg_cmake_configure)
ArdourSupportJE/vcpkg_installed/x64-windows/share/vcpkg-tool-meson/vcpkg_configure_meson.cmake:346 (vcpkg_cmake_get_vars)
ArdourSupportJE/vcpkg_installed/x64-windows/share/vcpkg-tool-meson/vcpkg_configure_meson.cmake:481 (vcpkg_generate_meson_cmd_args)
C:/Users/JohnE/AppData/Local/vcpkg/registries/git-trees/6c91a4d4382d4d271d13397214c536389fd4a122/portfile.cmake:42 (vcpkg_configure_meson)
scripts/ports.cmake:206 (include)

error: building glib:x64-windows failed with: BUILD_FAILED

Can anyone advise me as to whether or not I can fix this? For example, should I have maybe built some earlier version of the dependencies? Also, if someone can let me know which log file(s) would be appropriate I'd be happy to post them too.

[johne53]

Update (I've discovered something else that might be relevant...)

If I try to build an even earlier version of glib (ver 2.70.1) I see a different error:-

error: the baseline does not contain an entry for port tool-meson

whereas if I try a more recent version (ver 2.80.0) that one builds fine.

So I tried a completely different package (curl) and for that one I can go back quite a long way and the previous versions build fine.

So maybe it's just the case that some packages have retained good backwards compatibility whereas others haven't??

[dg0yt]

error: the baseline does not contain an entry for port tool-meson

If you choose an old baseline, you will get problems with ports which rely on more recent capabilities. You will be more successful with choosing a more recent baseline but pinning selected ports to old versions.

[johne53]

Oh I see.. that's something I didn't realise. Here's what I see (in git) for Glib:-

and you can see that the long SHA number for version 2.78.1 is 5c02b81 (which is the number I'd been using for my baseline). So are you saying that I can use one of the more recent numbers but still specify version 2.78.1?

[dg0yt]

Yes, with `overrides. https://learn.microsoft.com/en-us/vcpkg/users/versioning.concepts#constraint-resolution.
Prerequisite: you use manifest mode correctly. (Looking at past discussions.)

[johne53]

Yes I'm using manifest mode (which I thought I understood) but I must be doing something wrong. Let's say I'm building pango, which depends on glib (the one I want to set to ver 2.78.1). Here's how my vcpkg.json file would look at present:-

{
  "$comment": "baseline value is the latest commit in vcpkg repo as of 14.03.2026",
  "builtin-baseline": "4b77da7fed37817f124936239197833469f1b9a8",
  "dependencies": [
    "pango",

// Some other stuff

  ],
  "overrides": [
    {
      "name": "glib",
      "version": "2.78.1"
    },
    {
      "name": "cairo",
      "version": "1.18.0"
    },
    {
      "name": "pango",
      "version": "1.48.4"
    }
  ],
  "features": {

// Whatever
  
  }
}

and up to now I've been using a file called vcpkg-configuration.json looking like this:-

{
  "default-registry": {
    "kind": "git",
    "repository": "https://github.com/Microsoft/vcpkg",
    "baseline": "4b77da7fed37817f124936239197833469f1b9a8"
  },
  "registries": [
    {
      "kind": "git",
      "repository": "https://github.com/Microsoft/vcpkg",
      "baseline": "32565de58115a09f20e8a04230ca6b5ec2827674",
      "packages": [ "pango*", "pangowin*", "pangocairo*", "pangoft2*" ]
    }
  ]
}

So at the moment I'm not actually entering a baseline anywhere for glib. Is that the wrong approach?

[dg0yt]

The baseline isn't specifically for glib, but for the registry and general version resolution.

"builtin-baseline": "4b77da7fed37817f124936239197833469f1b9a8",

This would be March 2026, but your are explicitly taking pango ports from

"baseline": "32565de58115a09f20e8a04230ca6b5ec2827674",

which is May 2021. (AFAICS "pango*" should also catch everything matched by the other patterns.)

[johne53]

The baseline isn't specifically for glib, but for the registry and general version resolution.

So the baseline needs to be more recent than all the package versions I'm building? That's something I'd misunderstood.

I'm afraid the log files will be long gone by now but I'll experiment with the newer baseline next time I get a chance. Thanks once again for helping with this.

[dg0yt]

So the baseline needs to be more recent than all the package versions I'm building?

"Needs to be", no. It is more like it shouldn't be much older.

"Baseline" determines the default versions selected in manifest mode. In fact it reflects a state which should build because it was tested in vcpkg CI. (Your mileage may vary. There might have been known issues, and upstream sources or tools might have been deleted in the meantime.) So starting with a suitable baseline and a minimal set of extra version constraints should increase the chances for success.

OTOH updates and fixes can only be applied in new revisions. And these changes will only be tested with what is in the registry when the fix is submitted. Some changes might be mandatory, e.g. when an upstream tool is gone.

In any case, the more you pick versions across a long period of time, the more the build will be different from what was tested at a single point in time.

[dg0yt]

Also, if someone can let me know which log file(s) would be appropriate I'd be happy to post them too.

Start with those which are listed there:

See logs for more information:
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-dbg-CMakeCache.txt.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-rel-CMakeCache.txt.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-dbg-CMakeConfigureLog.yaml.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-rel-CMakeConfigureLog.yaml.log
D:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees\glib\cmake-get-vars_C_CXX-x64-windows-out.log