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 نمی‌تواند مخزن را دانلود کند

اگر به‌جای add_subdirectory دستی، کتابخانه را با FetchContent به‌صورت vendor کنید، اشکالات زمان پیکربندی معمولاً مشکل شبکه است نه مشکل 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 در حین پیکربندی CMake، git clone را اجرا می‌کند. پشت یک پراکسی یا فایروال شرکتی، یا روی یک runner CI بدون دسترسی به شبکه، این عملیات با Failed to clone repository شکست می‌خورد. برای رفع این مشکل:

  • متغیر HTTPS_PROXY/HTTP_PROXY را برای مرحلهٔ پیکربندی CMake تنظیم کنید، یا
  • مخزن را یک‌بار از قبل کلون کنید و 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() را فراهم می‌کند. در نسخهٔ فعلی این شش متد فقط اسکلت هستند که به‌طور مطلق false را برمی‌گردانند، بنابراین کدی که بر پایهٔ آن‌ها برای تمایز انواع مقدار XMP شاخه می‌گیرد همیشه مسیر “false” را انتخاب می‌کند.

به‌جای آن از بررسی‌های پیاده‌سازی‌شده استفاده کنید — IsString()، IsInteger()، IsDouble()، IsArray() — یا وقتی نوع مقدار از پیش از زمینه مشخص است، دسترسی‌گرهای متناظر (ToStringValue()، ToInteger()، ToDouble()، ToArray()) را مستقیماً صدا بزنید. تعداد کمی از انواع داخلی سطح-پایین (BitmapInfo‌ی سازندهٔ پیش‌فرض، و انواع داخلی Encoding و Value که توسط مدل شیء PDF استفاده می‌شوند) نیز شامل بدنه‌های اسکلت هستند که توسط کدهای معمول پردازش سند استفاده نمی‌شوند.

همچنین ببینید:

 فارسی