Troubleshooting
Bygg misslyckas med C++20-fel
Aspose.PDF FOSS för C++ kräver en C++20-kompilator — clang 16+, gcc 13+, eller MSVC 2022 17.5+. Om din byggnad misslyckas med fel såsom “designated initializers only allowed in C++20” eller “concepts require ‘-std=c++20’”, kompilerar det konsumerande projektet inte med C++20-standarden aktiverad.
Ställ in standarden explicit innan du lägger till biblioteket som en underkatalog:
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_subdirectory(aspose.pdf-foss-for-cpp)
target_link_libraries(your_app PRIVATE aspose_pdf_foss)På kommandoraden motsvarar detta -std=c++20 (clang/gcc) eller /std:c++20 (MSVC).
CMake-konfiguration misslyckas — Versionen är för gammal
Projektet kräver CMake 3.22 eller senare. Att köra en äldre CMake ger ett fel liknande:
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.22 or higher is required. You are running version 3.16.3Kontrollera din installerade version och uppgradera istället för att redigera den medföljande CMakeLists.txt:
cmake --versionInstallera en aktuell version från cmake.org eller din paket-hanterare — minsta versionen speglar generator- och språkfunktionerna som byggprocessen faktiskt använder, inte ett godtyckligt lägsta värde.
FetchContent misslyckas med att hämta förrådet
Om du vendor biblioteket med FetchContent istället för en manuell add_subdirectory, är fel under konfigurationstid vanligtvis ett nätverksproblem snarare än ett CMake-problem:
include(FetchContent)
FetchContent_Declare(
aspose_pdf_foss
GIT_REPOSITORY https://github.com/aspose-pdf-foss/Aspose.PDF-FOSS-for-Cpp.git
GIT_TAG main
)
FetchContent_MakeAvailable(aspose_pdf_foss)
target_link_libraries(your_app PRIVATE aspose_pdf_foss)FetchContent_MakeAvailable kör git clone under CMake-konfiguration. Bakom en företagsproxy eller brandvägg, eller på en luftsluten CI-körare, misslyckas detta med Failed to clone repository. Så här åtgärdar du det:
- Ställ in
HTTPS_PROXY/HTTP_PROXYför CMake-konfigurationssteget, eller - Klona förrådet i förväg en gång och peka
FETCHCONTENT_SOURCE_DIR_ASPOSE_PDF_FOSSpå den lokala utcheckningen så attFetchContentåteranvänder den istället för att hämta över nätverket, eller - Vendor källkoden direkt och använd
add_subdirectory(), som saknar nätverksberoende vid konfigurationstid.
Odefinierad referens / Oupplöst extern symbol vid länktid
Kompileringen lyckas men länkning misslyckas med undefined reference to Aspose::Pdf::Document::... (gcc/clang) eller ett unresolved external symbol fel (MSVC). Detta beror nästan alltid på en av två orsaker:
- Saknad länkningssteg —
target_link_libraries(your_app PRIVATE aspose_pdf_foss)saknas eller är felstavad.add_subdirectory()ensamt gör bara rubrikerna synliga; det länkar inte det statiska biblioteket. - Körtidsbibliotek / byggtyp-mismatch på MSVC — länkar en
Release-byggdaspose_pdf_foss.libtill enDebugkörbar (eller tvärtom) blandar inkompatibla C-runtimebibliotek och misslyckas medLNK2038missmatchningar. Bygg biblioteket och din applikation med sammaCMAKE_BUILD_TYPE(eller samma/MD//MDdruntime-biblioteksinställning).
XMP-metadata-typkontroller returnerar alltid falskt
XmpValue — den värdetyp som returneras från Document.Metadata()-poster — exponerar typkontrollhjälpare IsDateTime(), IsField(), IsNamedValue(), IsRaw(), IsNamedValues() och IsStructure(). I den aktuella releasen är dessa sex metoder stubbar som ovillkorligt returnerar false, så kod som grenar på dem för att särskilja XMP-värdeslagar alltid tar den “false” vägen.
Använd de implementerade kontrollerna istället — IsString(), IsInteger(), IsDouble(), IsArray() — eller anropa den matchande åtkomstfunktionen (ToStringValue(), ToInteger(), ToDouble(), ToArray()) direkt när värdets typ redan är känd från kontexten. Ett litet antal låg-nivå interna typer (BitmapInfos standardkonstruktor, och de interna Encoding och Value typerna som används av PDF-objektmodellen) innehåller också stub-kroppar som inte utnyttjas av vanlig dokumentbehandlingskod.