Building against a dependency that's been renamed

[johne53]

I'm trying to find out if libsigcpp) version 2 is still supported by vcpkg

I'm building glibmm at version 2.52 (which depends on libsigcpp). If I try an override looking like this:-

  "overrides": [
      "name": "glibmm",
      "version": "2.52.1"
    }
  ]

vcpkg tells me error: the baseline does not contain an entry for port libsigcpp-3/ After looking at the glibmm port I can fix that quite easily by adding an extra override:-

  "overrides": [
      "name": "glibmm",
      "version": "2.52.1"
    },
    {
      "$comment": "glibmm 2.76.0 and above depend on a package that has been renamed, so need to specify that too",
      "name": "libsigcpp-3",
      "version": "3.0.3#1"
    }
  ]

But according to the comment, that override should only be needed for glibmm2.76.0 and above. I'm pretty sure that glibmm2.52.1 used libsigcpp version 2 rather than 3. I found a list of libsigcpp revisions here:- https://vcpkg.link/ports/libsigcpp/versions and sigcpp ver2 definitely seems to be available but I can't find a way to use it. For example if I try this:-

  "overrides": [
      "name": "glibmm",
      "version": "2.52.1"
    },
    {
      "$comment": "glibmm 2.76.0 and above depend on a package that has been renamed, so need to specify that too",
      "name": "libsigcpp",
      "version": "2.10-3"
    }
  ]

vcpkg install gives me the same message as above. But if I change to this:-

  "overrides": [
      "name": "glibmm",
      "version": "2.52.1"
    },
    {
      "name": "libsigcpp-3",
      "version": "2.10-3"
    }
  ]

I then see this:-

error: no version database entry for libsigcpp-3 at 2.10-3.

Available versions:
  3.0.3#1
  3.0.3

So how do I use one the revisions from https://vcpkg.link/ports/libsigcpp/versions

[johne53]

Or an alternative thought...

If libsigcpp ver2 isn't available from vcpkg any more, might it be possible for me to add it somehow using vcpkg-configuration.json?

I'm not entirely sure what vcpkg-configuration.json is for, but from what I've read it seems like it can be useful if I need to add my own private packages to a build. And the vcpkg home page suggests that this is also supported. So does that offer a possible way for me to add libsigcpp ver2 locally?

[johne53]

I'd like to experiment with adding my own package to a build (I assume there's probably been discussions here already). Can anyone help me get started?

[Edit...] It's a bit patchy in parts but is this maybe the mechanism?

[Aleksandr Kovalko (gistrec)]

overrides only re-pin which version of a port to use — they can't bring back a port name (libsigcpp for v2) whose port files were removed from your baseline. The baseline you're pinning to only ships libsigcpp-3, so any "name": "libsigcpp" entry resolves to nothing

Two workable options:

1. Overlay-port (your vcpkg-configuration.json hunch is right). Copy the old ports/libsigcpp/ (portfile.cmake + vcpkg.json) from a vcpkg commit before the v3 rename into, say, ./vcpkg-overlays/libsigcpp/, then point at the parent dir from vcpkg-configuration.json:

   { "overlay-ports": ["./vcpkg-overlays"] }

   Now you can list libsigcpp in vcpkg.json and override its version normally. Docs: Overlay ports.

2. Pin builtin-baseline to a commit before the rename. That baseline still has ports/libsigcpp/ for v2 and a glibmm 2.52.1 that depends on it, so you can drop the libsigcpp-3 override entirely.

Overlay-ports are usually the more durable answer - they survive future baseline bumps

[johne53]

Hi Aleksandr Kovalko (@gistrec) and thanks for helping. I took a quick look at that Overlay ports entry you linked to and it doesn't look too difficult so whenever I can find some time I'll give it a try. What's confusing me is how to find a baseline that's earlier than the rename. I've attached an image showing the 15 earliest commits for ports/libsigcpp but it's not obvious where the rename occurred. Having said that, the 5 earliest commits still contain references to libsigcpp version 2 so can I safely assume they must be from before the rename occurred?

Ordinarily I would've assumed that the rename occurred at commit #df3c619b69 (i.e. the very earliest commit)

[Aleksandr Kovalko (gistrec)]

Quick note before the answer: it wasn't a rename, which is what makes the log confusing. Two parallel ports actually existed for a while:

• ports/libsigcpp/ was created in 2017 (df3c619b69) at v2.10 and stayed on v2 for about four years.
• ports/libsigcpp-3/ was added as a separate, new port on 2020-10-07 (59a20fb164, PR [libsigcpp-3] Add new port #13412) so people could opt into the v3 ABI alongside the v2 one.
• On 2021-04-26 (546813ae7b, PR [glib up to gtk] update and make it work with meson  #13100 "[glib up to gtk] update and make it work with meson") the existing libsigcpp port was upgraded in-place from 2.10-3 to 3.0.3 — same port name, completely different API. From that point on the two ports were effectively duplicates.
• On 2025-12-29 (55fab67aea, PR [Many ports] Delist ports whose port renaming was done a long time ago #49122 "Delist ports whose port renaming was done a long time ago") the now-redundant libsigcpp-3 was delisted.

So when you sort the file's commit log oldest-first, the first ~10 entries are v2 simply because the port stayed on v2 for four years — not because the boundary lives at the bottom of the log. The cut-over is in the middle, at PR #13100, and df3c619b69 is just the very first "add this port" commit.

For a baseline where libsigcpp is still v2, you want the commit just before PR #13100. a9b27ed5dffbf70b135eddb0c4729f3ca87f106c works — at that commit versions/baseline.json resolves to:

libsigcpp : 2.10-3 (port-version 2)
glibmm    : 2.52.1 (port-version 14)   ← already depends on libsigcpp v2

A minimal vcpkg.json:

{
  "name": "your-project",
  "version-string": "0",
  "builtin-baseline": "a9b27ed5dffbf70b135eddb0c4729f3ca87f106c",
  "dependencies": [ "glibmm" ]
}

With this baseline you don't need any overrides at all — glibmm resolves to 2.52.1 and pulls in libsigcpp v2 directly. One caveat: don't go much earlier than mid-2020, because the versions/ database didn't exist before then and manifest-mode resolution won't work cleanly.

---

A quicker way to find boundaries like this in the future, without scrolling the file log: look at versions/baseline.json (or versions/l-/libsigcpp.json for the full list) at a candidate commit and check what libsigcpp is pinned to — that's authoritative for what manifest mode will see.

[Aleksandr Kovalko (gistrec)]

My previous comment was about a possible local workaround through an overlay/custom port.

For the registry itself, I think the cleaner long-term fix may be to update/fix the libsigcpp port metadata and version database, because the confusing part is that users can request libsigcpp >= 2.10.8, but the available vcpkg version entries do not seem to line up with the upstream/project history.

[johne53]

Aleksandr Kovalko (@gistrec)

For the registry itself, I think the cleaner long-term fix may be to update/fix the libsigcpp port metadata and version database, because the confusing part is that users can request libsigcpp >= 2.10.8, but the available vcpkg version entries do not seem to line up with the upstream/project history.

I just wanted to find out if this is still under consideration? (please don't let it slip off the radar)

[johne53]

Thanks for all your help with this Aleksandr Kovalko (@gistrec)

If I use your vcpkg.json and do a --dry-run it does look like all the right dependencies will get built at the right versions. And for a real build, (maybe I set something up wrong?) the earliest dependency (zlib) did get built but the 2nd dependency (pcre) failed with this output:-

Downloading https://ftp.pcre.org/pub/pcre/pcre-8.44.zip -> pcre-8.44.zip
error: curl operation failed with error code 60 (SSL peer certificate or SSH remote key was not OK).
error: Not a transient network error, won't retry download from https://ftp.pcre.org/pub/pcre/pcre-8.44.zip
note: If you are using a proxy, please ensure your proxy settings are correct.
Possible causes are:
1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable to `https://address:port`.
This is not correct, because `https://` prefix claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr, etc...) is an HTTP proxy.
Try setting `http://address:port` to both HTTP_PROXY and HTTPS_PROXY instead.
2. If you are using Windows, vcpkg will automatically use your Windows IE Proxy Settings set by your proxy software. See: https://github.com/microsoft/vcpkg-tool/pull/77
The value set by your proxy might be wrong, or have same `https://` prefix issue.
3. Your proxy's remote server is out of service.
If you believe this is not a temporary download server failure and vcpkg needs to be changed to download this file from a different location, please submit an issue to https://github.com/Microsoft/vcpkg/issues
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:136 (message):
  Download failed, halting portfile.
Call Stack (most recent call first):
  buildtrees/versioning_/versions/pcre/69e232f12c4e3eab4115f0672466a6661978bea2/portfile.cmake:10 (vcpkg_download_distfile)
  scripts/ports.cmake:206 (include)

error: building pcre: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 pcre:x64-windows: 508 ms
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.

[Edit...] Modifying your vcpkg.json made pcre build correctly:-

{
  "builtin-baseline": "a9b27ed5dffbf70b135eddb0c4729f3ca87f106c",
  "dependencies": [
    "glibmm"
  ],
  "overrides": [
    {
      "name": "pcre",
      "version": "8.45#2"
    }
  ]
}

So tomorrow when I've a bit more time I'll try the full build and see how it goes!