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??

[Kai Pastor (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?

[Kai Pastor (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?

[Kai Pastor (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.

[Kai Pastor (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.

[Kai Pastor (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

[Aleksandr Kovalko (gistrec)]

Your manifest structure looks correct to me

A recent builtin-baseline is the right way to make sure vcpkg can resolve the registry metadata and tool dependencies. Then overrides can be used to pin selected ports to specific versions. You do not need a separate baseline entry just for glib

So the important part is probably not the manifest layout, but the actual build failure

The failure happens while vcpkg_configure_meson() is calling vcpkg_cmake_get_vars() to detect the compiler/build environment. The useful error should be in the log mentioned by vcpkg, something like:

cmake-get-vars_C_CXX-x64-windows-out.log

I would check that file first and look for the first CMake error above the final ninja failure

Given that glib 2.80.0 builds for you but 2.78.1 does not, one likely explanation is that the older glib port version does not work cleanly with the current vcpkg helper scripts/tooling. But the log should confirm the exact reason

Practical options:

1. If glib 2.80.0 is acceptable, use that version.
2. If you need exactly glib 2.78.1, inspect the cmake-get-vars... log first.
3. If it turns out to be a portfile/tooling compatibility issue, an overlay port may be the cleanest workaround: copy a newer working glib port recipe and adjust it to build 2.78.1.

But no, I would not add a separate baseline for glib. Your use of builtin-baseline + overrides is the expected approach

[johne53]

Thanks Aleksandr Kovalko (@gistrec) - unfortunately the log files won't be available any more. Due to problems with hard drive space, I've needed to uninstall vcpkg for the time being. But thanks to all the help in this thread I think I'm (hopefully!) starting to understand the situation with baselines.

Having said that, I've never heard the term overlay port before so that's beginning to make me wonder. Are they something different from conventional ports?

[Kai Pastor (dg0yt)]

If I type "learn vcpkg overlay ports" in to a traditional search engine, this is the first hit:
https://learn.microsoft.com/en-us/vcpkg/concepts/overlay-ports.
It is not what you dive into when you are still struggling to learn basic usage.

[johne53]

Thanks Kai Pastor (@dg0yt) (and for all your earlier help). I just read that article (albeit very briefly - and before I'd had my breakfast!) and I'm sure it'll start making sense once I've read it a few more times.

The bit I didn't quite get from my initial reading was how it'd help if I need to build earlier versions of various packages. Do I just need to read it more carefully?

[Kai Pastor (dg0yt)]

If I type "learn vcpkg overlay ports" in to a traditional search engine, this is the first hit: https://learn.microsoft.com/en-us/vcpkg/concepts/overlay-ports. It is not what you dive into when you are still struggling to learn basic usage.

You don't need overlay ports at this point.
(Overlay ports are useful for custom ports, for custom modifications/fixes and for updates to historical versions.)

[Kai Pastor (dg0yt)]

Maybe you should keep things simple and stick to just vcpkg.json and the "builtin" registry instead of trying advanced difficulty with a) overriding the "default" registry and b) adding a second registry.

[johne53]

Do you mean abandoning the file called vcpgk-configuration.json and just stick with vcpkg.json?

[Kai Pastor (dg0yt)]

Yes.

[johne53]

Many thanks Kai Pastor (@dg0yt) I'll give that a try.

Unfortunately I'm currently fighting a problem with low disk space so it'll have to wait for a while (I needed to uninstall the biggest programs, including vcpkg).

I might try buying a USB memory stick and see how that works.

[johne53]

Hello again Kai Pastor (@dg0yt) and thanks for all your help with this. I purchased a USB memory drive last weekend and restored my backup of vcpkg. I then abandoned vcpkg-configuration.json and rebuilt just using my original copy of vcpkg.json - and you're right... it worked!! Without me needing vcpkg-configuration.json at all. I don't know who originally told me that vcpkg-configuration.json was needed (or maybe I misunderstood??) but it doesn't seem to help at all in this situation.

Having said that, I've just posted a new question where vcpkg-configuration.json might just be the answer.