Freigeben über

Handbuch zur Problembehandlung bei der Binären Zwischenspeicherung

  • Artikel

Dieses Handbuch richtet sich an Benutzer, die Probleme mit der binären Zwischenspeicherung haben.

Aktivieren von vcpkg-Debugginginformationen

Es wird dringend empfohlen, die Debugausgabe zu aktivieren, wenn Sie diesem Handbuch folgen.

  • Klassischer Modus: Fügen Sie --debug Ihrem Befehlsaufruf hinzu.
  • CMake-Toolkette: Fügen Sie -DVCPKG_INSTALL_OPTIONS="--debug" in Ihrem CMake-Konfigurationsaufruf oder in Ihrer CMakePresets.json Datei hinzu.
  • MSBuild/Visual Studio: Legen Sie die Eigenschaft VcpkgAdditionalInstallOptions auf --debug.
  • Legen Sie die Umgebungsvariable VCPKG_INSTALL_OPTIONS auf --debug fest.

Fehler beim NuGet-Push an {url}

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

Wenn Sie eine NuGet-Binärquelle verwenden, wird der folgende Fehler angezeigt:

Pushing NuGet to {url} failed. Use --debug for more information.

Wenn Sie eine NuGet-Konfigurationsdatei-Binärquelle verwenden, wird der folgende Fehler angezeigt:

Pushing NuGet config to {url} failed. Use --debug for more information.

Dieser Fehler tritt auf, wenn vcpkg versucht und die NuGet-Befehlszeile zum Hochladen von Paketen in einen NuGet-Feed nicht verwendet.

Ursache 1: Unzureichende Benutzerschreibberechtigungen

Es wird die folgende Fehlermeldung angezeigt:

System.Net.Http.HttpRequestException: Response status code does not indicate success: 403 (Forbidden - User <user> lacks permission to complete this action. You need to have 'AddPackage'.

Push wurde von der Remotequelle abgelehnt, da der Benutzer nicht über ausreichende Schreibberechtigungen verfügt.

  • Vergewissern Sie sich, dass Ihr Benutzer oder Ihre Benutzergruppe Schreibberechtigungen besitzt. In NuGet muss der Benutzer mindestens eine Mitwirkenderolle für den Feed sein.

Ursache 2: Falsch konfigurierte NuGet-Feed-URL

Möglicherweise wird der Fehler angezeigt:

System.Net.Http.HttpRequestException: Response status code does not indicate success: 405 (Method Not Allowed).

Der Server hat die Pushanforderung von NuGet abgelehnt, da sie die Anforderungsmethode nicht erkannt hat.

  • Stellen Sie sicher, dass der URI in Ihrer binären Quelle korrekt ist und dass er in der Regel <feed base url>/nuget/v3/index.jsonan den Dienstindex des Feeds leitet.

Zusätzliche NuGet-Ressourcen

In der NuGet-Dokumentation finden Sie Richtlinien zum Herstellen einer Verbindung mit und Veröffentlichung in einem NuGet-Feed.

Fehler beim Cacheupload

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

Beim Hochladen eines Binärpakets in den Cache treten Fehler auf.

Ursache 1: Fehler beim Hochladen des Binären Cacheanbieters

Uploads können aus verschiedenen Gründen fehlschlagen, und Fehlermeldungen sind in der Regel anbieterspezifisch.

  • Stellen Sie sicher, dass Sie sich bei Ihrem Cache authentifiziert haben. Verschiedene Anbieter authentifizieren sich unterschiedlich.
  • Überprüfen Sie, ob Sie den richtigen URI für Den Cache angegeben haben.
  • Informationen zur Push-Problembehandlung , wenn Sie NuGet als binäre Quelle verwenden.
  • Lesen Sie die Dokumentation oder den Leitfaden zur Problembehandlung Ihres jeweiligen Anbieters.

Leerer Binärcache

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

Obwohl keine Fehler aufgetreten sind und die vcpkg-Installation erfolgreich war, bleibt der binäre Cache leer. Wenn Sie Fehler beobachtet haben, wenden Sie sich an die Push-Problembehandlung für NuGet und upload-Problembehandlung für andere Anbieter.

Ursache 1: vcpkg verfügt nicht über Schreibberechtigungen für den Binärcache

Die folgende Meldung fehlt in der Ausgabe.

Uploading binaries for 'rapidjson:x64-windows' to <binary source> source <url>.
Stored binaries in 1 destinations in 1.5 s.

vcpkg hat das Hochladen des Binärpakets in den Binären Cache übersprungen.

  • Stellen Sie sicher, dass die Konfiguration des binären Caches auf write oder readwrite

Bibliotheken werden neu erstellt, anstatt den binären Remotecache zu verwenden.

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

Ihr System erstellt Bibliotheken lokal neu, auch wenn das erforderliche Binärpaket im Remote-Binärcache verfügbar ist.

Die folgende Meldung fehlt in der Ausgabe.

Restored 1 package(s) from <remote binary cache> in 1.1 s. Use --debug to see more details.

Ursache 1: vcpkg verfügt nicht über Leseberechtigungen aus dem Remote-Binärcache

vcpkg wählt aus, ihren Standardmäßigen binären Cache über den Remotecache zu lesen.

  • Stellen Sie sicher, dass die Konfiguration des binären Caches auf read oder readwrite

Ursache 2: Der Remote-Binärcache ist leer

Der Remotecache sollte eine Liste der binärpakete enthalten, die Sie übertragen haben.

Ursache 3: Unterschiede zwischen lokalen und Remotebuildumgebungen

Jedes Paket im Binären Cache wird mit einem ABI-Hash bezeichnet, der Compilerversionen, Quellen und andere Informationen enthält, um zwischen binären Paketen zu unterscheiden. Wenn der lokal berechnete ABI-Hash nicht mit dem remote gespeicherten Hash übereinstimmt, wird das Paket nicht abgerufen.

  • Lesen Sie den Leitfaden zur Problembehandlung bei ABI-Hashfehlern, um die Ursache zu ermitteln.

Unerwartete oder häufige Bibliotheksneuerneuerungen

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

In einer unveränderten Umgebung und ohne Aktualisierung von vcpkg finden Sie sich immer noch, bibliotheken occassional neu zu erstellen.

Ursache 1: Nicht erkannte Änderungen in der Buildumgebung

Jedes Paket im Binären Cache wird mit einem ABI-Hash bezeichnet, der Compilerversionen, Quellen und andere Informationen enthält, um zwischen binären Paketen zu unterscheiden. Wenn der lokal berechnete ABI-Hash nicht mit dem remote gespeicherten Hash übereinstimmt, wird das Paket nicht abgerufen.

  • Lesen Sie den Leitfaden zur Problembehandlung bei ABI-Hashfehlern, um die Ursache zu ermitteln.

Problembehandlung bei ABI-Hashkonflikten

Wichtig

Aktualisieren Sie Ihr vcpkg-Tool auf die neueste Version. Aktivieren Sie außerdem die Debugausgabe für umfassende Fehlerprotokolle.

Diese Anleitung dient benutzern, zu diagnostizieren, warum sie unterschiedliche ABI-Hashes für zwei identisch benannte Binärpakete haben.

Vergleichen von zwei Binärpaketen

Die Ermittlung des Unterschieds zwischen zwei identisch benannten Paketen erfordert einen Vergleich verschiedener Daten: Quellen, Toolversionen, Compiler und Zielplattformen. Der ABI-Hash stellt eine präzise Darstellung dieser Daten bereit. Bei der Berechnung eines ABI-Hashs berücksichtigt vcpkg alle relevanten Daten, einschließlich Dateiinhalte, Toolversionen und Systemdetails. Er erstellt einen Hash für jeden Datenpunkt und kombiniert diese Hashes dann in einem einzelnen Wert für das Binärpaket.

ABI-Hashvergleich für Binärpaket

Der ABI-Hash der Bibliotheks-Zlib lautet bb1c96759ac96102b4b18215db138daedd3eb16c2cd3302ae7bffab2b643eb87:

[DEBUG] Trying to hash <path>\buildtrees\zlib\x86-windows.vcpkg_abi_info.txt
[DEBUG] <path>\buildtrees\zlib\x86-windows.vcpkg_abi_info.txt has hash bb1c96759ac96102b4b18215db138daedd3eb16c2cd3302ae7bffab2b643eb87

Wenn sich der Hash zwischen den Ausführungsläufen für dieselbe Bibliothek ändert, gibt dies an, dass die beiden Pakete unterschiedlich sind.

Compilerversion ABI-Hashvergleich

Überprüfen Sie, ob sich die Version des Compilers zwischen den Ausführungsläufen geändert hat.

[DEBUG] -- The C compiler identification is MSVC 19.36.32538.0
[DEBUG] -- The CXX compiler identification is MSVC 19.36.32538.0
[DEBUG] #COMPILER_HASH#f5d02a6542664cfbd4a38db478133cbb1a18f315

Der Compilerhash lautet f5d02a6542664cfbd4a38db478133cbb1a18f315.

ABI-Hasheintragsvergleich

Vergleichen Sie ABI-Einträge für jedes Paket. Ein Eintrag stellt eine Information dar, die zum endgültigen Hash beiträgt.

[DEBUG] <abientries for zlib:x86-windows>
[DEBUG]   0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch|750b9542cb55e6328cca01d3ca997f1373b9530afa95e04213168676936e7bfa
[DEBUG]   0002-skip-building-examples.patch|835ddecfed752e0f49be9b0f8ff7ba76541cb0a150044327316e22ca84f8d0c2
[DEBUG]   0003-build-static-or-shared-not-both.patch|d6026271dcb3d8fc74b41e235620ae31576a798e77aa411c3af8cd9e948c02b1
[DEBUG]   0004-android-and-mingw-fixes.patch|37a43eddbcb1b7dde49e7659ae895dfd0ff1df66666c1371ba7d5bfc49d8b438
[DEBUG]   cmake|3.26.2
[DEBUG]   features|core
[DEBUG]   portfile.cmake|ac63047b644fa758860dd7ba48ff9a13b058c6f240b8e8d675b8fbba035976be
[DEBUG]   ports.cmake|5a8e00cedff0c898b1f90f7d129329d0288801bc9056562b039698caf31ff3f3
[DEBUG]   post_build_checks|2
[DEBUG]   powershell|7.3.6
[DEBUG]   triplet|x86-windows
[DEBUG]   triplet_abi|3e71dd1d4afa622894ae367adbbb1ecbd42c57c51428a86b675fa1c8cad3a581-36b818778ba6f2c16962495caedb9a7b221d5be4c60de1cd3060f549319a9931-f5d02a6542664cfbd4a38db478133cbb1a18f315
[DEBUG]   usage|be22662327df993eebc437495add75acb365ab18d37c7e5de735d4ea4f5d3083
[DEBUG]   vcpkg-cmake|1b3dac4b9b0bcbef227c954b495174863feebe3900b2a6bdef0cd1cf04ca1213
[DEBUG]   vcpkg-cmake-wrapper.cmake|5d49ef2ee6448479c2aad0e5f732e2676eaba0411860f9bebabe6002d66f57d1
[DEBUG]   vcpkg.json|bc94e2540efabe36130a806381a001c57194e7de67454ab7ff1e30aa15e6ce23
[DEBUG]   vcpkg_copy_pdbs|d57e4f196c82dc562a9968c6155073094513c31e2de475694143d3aa47954b1c
[DEBUG]   vcpkg_fixup_pkgconfig|588d833ff057d3ca99c14616c7ecfb5948b5e2a9e4fc02517dceb8b803473457
[DEBUG]   vcpkg_from_git|8f27bff0d01c6d15a3e691758df52bfbb0b1b929da45c4ebba02ef76b54b1881
[DEBUG]   vcpkg_from_github|b743742296a114ea1b18ae99672e02f142c4eb2bef7f57d36c038bedbfb0502f
[DEBUG]   vcpkg_replace_string|d43c8699ce27e25d47367c970d1c546f6bc36b6df8fb0be0c3986eb5830bd4f1
[DEBUG] </abientries>

Hinweis

Der triplet_abi Eintrag enthält drei Hashes: den Hash des Dateiinhalts des x86-windows Triplets, der windows.cmake Toolkette und des Compilerhashs. Diese Hashes würden sich ändern, wenn Sie sich für eine andere Plattform entschieden haben.

Fehlende Übereinstimmung 1: Portdateien

Portdateien umfassen Portskripts (portfile.cmake, ), Patchdateien (*.patch) oder eine andere Datei im Portsverzeichnis: ports/<library>/*vcpkg.json.

Ursache 1: CI oder Pipeline hat die Portregistrierung aktualisiert

Bevor vcpkg in Ihrem CI ausgeführt wurde, klonte es das neueste vcpkg-Repository.

  • Stellen Sie bei Verwendung git clone https://github.com/microsoft/vcpkg des bootstrap Skripts sicher, dass Sie einen bestimmten Commit auschecken.
  • Erwägen Sie das Hinzufügen von vcpkg als Git-Untermodule zu Ihrem Projekt.

Ursache 2: GitHub-Aktionen aktualisiert vcpkg

Sie verwenden die Systemkopie von vcpkg, die von GitHub Actions bereitgestellt wurde, die aktualisiert wurde.

  • Klonen Sie Ihre eigene Kopie von vcpkg.
  • Erwägen Sie, vcpkg zu einem Git-Untermodul in Ihrem Projekt zu erstellen.

Nicht übereinstimmende 2: vcpkg CMake Hilfsfunktionen

CMake-Hilfsfunktionen befinden sich im Skriptverzeichnis: scripts/*, und beginnen in der Regel mit vcpkg_.

Ursache 1: CI oder Pipeline aktualisierte Hilfsskripts

Bevor vcpkg in Ihrem CI ausgeführt wurde, klonte es das neueste vcpkg-Repository.

  • Stellen Sie bei Verwendung git clone https://github.com/microsoft/vcpkg des bootstrap Skripts sicher, dass Sie einen bestimmten Commit auschecken.
  • Erwägen Sie das Hinzufügen von vcpkg als Git-Untermodule zu Ihrem Projekt.

Ursache 2: GitHub-Aktionen aktualisiert vcpkg

Sie verwenden die Systemkopie von vcpkg, die von GitHub Actions bereitgestellt wurde, die aktualisiert wurde.

  • Klonen Sie Ihre eigene Kopie von vcpkg.
  • Erwägen Sie, vcpkg zu einem Git-Untermodul in Ihrem Projekt zu erstellen.

Nicht übereinstimmend 3: Compilerversion

vcpkg hat Ihre Abhängigkeiten mit einer anderen Version des Compilers neu erstellt.

Ursache 1: Der Visual Studio C++-Compiler wird automatisch aktualisiert.

Visual Studio hat die C++-Workload, einschließlich des Compilers, zwischen den Ausführungen automatisch aktualisiert. Selbst Nebenversionsupdates führen dazu, dass vcpkg den Satz von Bibliotheken neu erstellt.

Ursache 2: Die Bibliothek wurde auf einem anderen Computer als dem Computer erstellt, der zum Verbrauch verwendet wurde.

Ein Computer hat das Binärpaket in einem Remotecache erstellt und veröffentlicht. Ein anderer Computer, der in der Regel für die Entwicklung verwendet wird, nutzte die zwischengespeicherte Bibliothek.

  • Verwenden Sie dieselbe C++-Compilerversion lokal wie auf Ihrem Remotecomputer. Für Visual Studio sollten Sie einen Bootstrapper mit fester Version in Betracht ziehen.
  • Erstellen Sie Ihre Abhängigkeiten lokal für Entwicklungszwecke neu. Testen und beheben Sie Probleme später während der kontinuierlichen Integration.

Ursache 3: Das selbst gehostete Image hat den Compiler aktualisiert.

Das zugrunde liegende Image, das Sie zum Erstellen von vcpkg-Abhängigkeiten verwendet haben, wurde geändert, wodurch die Compilerversion aktualisiert wurde.

  • An ein stabiles und versionsiertes Image anheften. Stellen Sie sicher, dass Sie das neueste Image nicht abrufen, sodass die zugrunde liegenden Tools oder Compiler nicht automatisch zwischen den Ausführungsläufen aktualisiert werden.
  • Wenn Sie das Image häufig aktualisieren müssen, heften Sie die C++-Compilertools bei der Erstellung Ihres Images an eine bestimmte Version an.

Ursache 4: GitHub Hosted Runners hat den zugrunde liegenden Compiler aktualisiert.

Gehostete GitHub-Runner aktualisieren Compiler und Tools wöchentlich.

  • Derzeit gibt es keine Möglichkeit, Das Image zu beheben und zu verhindern, dass die Tools und Compilerversion regelmäßig aktualisiert werden. Weitere Optionen finden Sie im Abschnitt "Alternative Lösungen".

Nicht übereinstimmend 4: Die Version der Zwischenläufe geänderten Tools.

Die Version der Tools, die zum Erstellen Ihrer Bibliotheken, CMake oder PowerShell verwendet werden, wurde zwischen Denläufen geändert.

Ursache 1: Visual Studio wird automatisch aktualisiert.

Visual Studio wird automatisch aktualisiert, einschließlich aller Tools, zwischen den Ausführungen. Selbst Nebenversionsupdates führen dazu, dass vcpkg den Satz von Bibliotheken neu erstellt.

Ursache 2: Die Bibliothek wurde auf einem anderen Computer als dem Computer erstellt, der zum Verbrauch verwendet wurde.

Ein Computer hat das Binärpaket in einem Remotecache erstellt und veröffentlicht. Ein anderer Computer, der in der Regel für die Entwicklung verwendet wird, nutzte die zwischengespeicherte Bibliothek.

  • Verwenden Sie die gleichen Toolversionen lokal wie auf Ihrem Remotecomputer.
  • Erstellen Sie Ihre Abhängigkeiten lokal für Entwicklungszwecke neu. Testen und beheben Sie Probleme später während der kontinuierlichen Integration.
  • Fügen Sie --x-abi-tools-use-exact-versions Ihren vcpkg-Aufruf hinzu. Dadurch wird die ABI Ihrer Tools basierend auf der Version in vcpkgTools.xml; vcpkg ruft bei Bedarf eine eigene Kopie ab.

Ursache 3: Selbst gehostetes Image hat die Tools aktualisiert.

Das zugrunde liegende Image, das Sie zum Erstellen von vcpkg-Abhängigkeiten verwendet haben, wurde geändert, was die Versionen aller verwendeten Tools sind.

  • An ein stabiles und versionsiertes Image anheften. Stellen Sie sicher, dass Sie das neueste Image nicht abrufen, sodass die zugrunde liegenden Tools nicht automatisch zwischen den Ausführungsläufen aktualisiert werden.
  • Wenn Sie das Bild häufig aktualisieren müssen, heften Sie alle relevanten Tools an eine bestimmte Version an, wenn Sie Ihr Image erstellen.
  • Fügen Sie --x-abi-tools-use-exact-versions Ihren vcpkg-Aufruf hinzu. Dadurch wird die ABI Ihrer Tools basierend auf der Version in vcpkgTools.xml; vcpkg ruft bei Bedarf eine eigene Kopie ab.

Ursache 4: GitHub Hosted Runners aktualisierte zugrunde liegende Tools.

Gehostete GitHub-Runner aktualisieren Compiler und Tools wöchentlich.

  • Fügen Sie --x-abi-tools-use-exact-versions Ihren vcpkg-Aufruf hinzu. Dadurch wird die ABI Ihrer Tools basierend auf der Version in vcpkgTools.xml; vcpkg ruft bei Bedarf eine eigene Kopie ab.

Weitere Optionen

Wenn die oben genannten Optionen nicht funktionieren, sollten Sie die folgenden Problemumgehungen berücksichtigen:

  • Dient vcpkg export zum Erstellen eines eigenständigen Archivs Ihrer Abhängigkeiten, anstatt sie aus einem Manifest wiederherzustellen.
  • Erwägen Sie die Verwendung eines selbst gehosteten Docker-Images zum Erstellen Ihrer Bibliotheken
  • Führen Sie eine zusätzliche fortlaufende Integration durch, die vcpkg-Bibliotheken in regelmäßigen Abständen erstellt (z. B. täglich oder wöchentlich)

Das Problem ist hier nicht aufgeführt

Wenn Ihr Problem hier nicht aufgeführt ist, besuchen Sie unser Repository , um ein neues Problem zu erstellen.