Troubleshooting

Troubleshooting

הבנייה נכשלת עם שגיאות C++20

Aspose.PDF FOSS ל-C++ דורש מהדר C++20 — clang 16+, gcc 13+, או MSVC 2022 17.5+. אם הבנייה שלך נכשלת עם שגיאות כגון “designated initializers only allowed in C++20” או “concepts require ‘-std=c++20’”, הפרויקט הצרכן אינו מקמפל עם סטנדרט C++20 מופעל.

הגדר את הסטנדרט במפורש לפני הוספת הספרייה כתת-ספרייה:

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)

בשורת הפקודה זה תואם ל--std=c++20 (clang/gcc) או /std:c++20 (MSVC).

הקונפיגורציה של CMake נכשלת — גרסה ישנה מדי

הפרויקט דורש CMake 3.22 או גרסה מאוחרת יותר. הרצת גרסה ישנה של CMake מייצרת שגיאה דומה ל-:

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.22 or higher is required.  You are running version 3.16.3

בדוק את גרסת ההתקנה שלך ושדרג במקום לערוך את CMakeLists.txt המסופק:

cmake --version

התקן גרסה עדכנית מ- cmake.org או ממנהל החבילות שלך — גרסת המינימום משקפת את הג’נרטור ותכונות השפה שהבנייה משתמשת בהן בפועל, ולא ערך מינימלי שרירותי.

FetchContent נכשל בהורדת המאגר

אם אתה משלב את הספרייה עם FetchContent במקום add_subdirectory ידני, תקלות בזמן הקונפיגורציה הן בדרך כלל בעיית רשת ולא בעיית CMake:

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 מריץ את git clone במהלך קונפיגורציית CMake. מאחורי פרוקסי תאגידי או חומת אש, או על משגר CI מבודד, זה נכשל עם Failed to clone repository. כדי לתקן זאת:

  • הגדר את HTTPS_PROXY/HTTP_PROXY עבור שלב הקונפיגורציה של CMake, או
  • הצע מראש (pre-clone) את המאגר פעם אחת והפנה את FETCHCONTENT_SOURCE_DIR_ASPOSE_PDF_FOSS לבדיקה המקומית כך ש-FetchContent ישתמש בו מחדש במקום למשוך מהרשת, או
  • השתמש ב-vendor של המקור ישירות והשתמש ב-add_subdirectory(), שאין לו תלות ברשת בזמן הקונפיגורציה.

הפנייה אינה מוגדרת / סמל חיצוני שלא נפתר בזמן הקישור

הקומפילציה מצליחה אך הקישור נכשל עם undefined reference to Aspose::Pdf::Document::... (gcc/clang) או עם שגיאת unresolved external symbol (MSVC). זה כמעט תמיד אחד משני הגורמים:

  1. שלב קישור חסר — target_link_libraries(your_app PRIVATE aspose_pdf_foss) חסר או כתוב בטעות. add_subdirectory() ביחודו רק מציג את הקבצים הראשיים; הוא אינו מקשר את הספרייה הסטטית.
  2. אי-התאמה בין ספריית הריצה / סוג הבנייה ב-MSVC — קישור של Release-בנוי aspose_pdf_foss.lib לתוך Debug קובץ הפעלה (או להפך) מערבב ספריות זמן ריצה של C שאינן תואמות ונכשל עם LNK2038 אי-התאמות. בנה את הספרייה ואת היישום שלך עם אותו CMAKE_BUILD_TYPE (או עם אותו /MD//MDd הגדרת ספריית זמן ריצה).

בדיקות סוג מטא-נתונים של XMP תמיד מחזירות false

XmpValue — סוג הערך המוחזר מ-Document.Metadata() — חושף עזרי בדיקת סוגים IsDateTime(), IsField(), IsNamedValue(), IsRaw(), IsNamedValues(), ו-IsStructure(). בגרסה הנוכחית שש השיטות הן stubs שמחזירים באופן בלתי מותנה false, ולכן קוד המתבסס עליהם כדי להבדיל בין סוגי ערכי XMP תמיד נוטה לנתיב “false”.

השתמש בבדיקות המיושמות במקום — IsString(), IsInteger(), IsDouble(), IsArray() — או קרא למקבל המתאים (ToStringValue(), ToInteger(), ToDouble(), ToArray()) ישירות כאשר סוג הערך כבר ידוע מהקשר. מספר קטן של סוגים פנימיים ברמת נמוכה (BitmapInfo עם בנאי ברירת המחדל שלו, והסוגים הפנימיים Encoding ו-Value המשמשים במודל האובייקט של PDF) גם מכילים גופי stub שאינם מנוצלים בקוד טיפוסי של עיבוד מסמכים.

ראה גם

 עברית