সাধারণ সমস্যা এবং সমাধান

এই দস্তাবেজটি NDK ব্যবহার করার সময় আপনার সম্মুখীন হতে পারে এমন সবচেয়ে সাধারণভাবে সম্মুখীন হওয়া অ-বাগগুলির একটি আংশিক তালিকা এবং তাদের সমাধানগুলি (যদি উপলব্ধ থাকে)৷

পুরানো API স্তরের সাথে _FILE_OFFSET_BITS=64 ব্যবহার করা হচ্ছে

ইউনিফাইড হেডারের আগে, NDK _FILE_OFFSET_BITS=64 সমর্থন করে না। আপনার অ্যাপ তৈরি করার সময় আপনি যদি এটি সংজ্ঞায়িত করেন তবে এটি নীরবে উপেক্ষা করা হয়েছিল। _FILE_OFFSET_BITS=64 বিকল্পটি এখন ইউনিফাইড হেডারগুলির সাথে সমর্থিত, কিন্তু অ্যান্ড্রয়েডের পুরানো সংস্করণগুলিতে off_t API-এর খুব কমই একটি off64_t ভেরিয়েন্ট হিসাবে উপলব্ধ ছিল। অতএব, পুরানো API স্তরের সাথে এই বৈশিষ্ট্যটি ব্যবহার করার ফলে কম ফাংশন উপলব্ধ হয়।

এই সমস্যাটি r16 ব্লগ পোস্টে এবং বায়োনিক ডকুমেন্টেশনে বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

সমস্যা : আপনার বিল্ড এমন API-এর জন্য জিজ্ঞাসা করছে যা আপনার minSdkVersion এ বিদ্যমান নেই।

সমাধান : _FILE_OFFSET_BITS=64 নিষ্ক্রিয় করুন বা আপনার minSdkVersion বাড়ান।

mmap এর অঘোষিত বা অন্তর্নিহিত সংজ্ঞা

আপনি C++ এ নিম্নলিখিত ত্রুটি দেখতে পারেন:

ত্রুটি: অঘোষিত শনাক্তকারী 'mmap' ব্যবহার

বা সি-তে নিম্নলিখিত ত্রুটি:

সতর্কতা: ফাংশন 'mmap'-এর অন্তর্নিহিত ঘোষণা C99-এ অবৈধ

_FILE_OFFSET_BITS=64 ব্যবহার করা C লাইব্রেরীকে mmap এর পরিবর্তে mmap64 ব্যবহার করার নির্দেশ দেয়। mmap64 android-21 পর্যন্ত উপলব্ধ ছিল না। যদি আপনার minSdkVersion মান 21-এর কম হয়, C লাইব্রেরিতে _FILE_OFFSET_BITS=64 এর সাথে সামঞ্জস্যপূর্ণ কোনো mmap থাকে না, তাই ফাংশনটি অনুপলব্ধ।

minSdkVersion ডিভাইস API স্তরের চেয়ে বেশি সেট করা হয়েছে

এনডিকে-এর সাথে আপনি যে API স্তরটি তৈরি করেন সেটি জাভার জন্য compileSdkVersion এর চেয়ে আলাদা অর্থ রয়েছে। NDK API স্তর হল আপনার অ্যাপের সর্বনিম্ন সমর্থিত API স্তর। ndk-বিল্ডে, এটি আপনার APP_PLATFORM সেটিং। CMake এর সাথে, এটি হল -DANDROID_PLATFORM

যেহেতু ফাংশনের রেফারেন্সগুলি সাধারণত লাইব্রেরিগুলিকে লোড করার সময় সমাধান করা হয় যখন সেগুলিকে প্রথম কল করা হয় না, আপনি এমন APIগুলি উল্লেখ করতে পারবেন না যেগুলি সর্বদা উপস্থিত থাকে না এবং API স্তরের চেকের সাথে তাদের ব্যবহার রক্ষা করে৷ যদি তারা এ সব উল্লেখ করা হয়, তারা উপস্থিত হতে হবে.

সমস্যা : আপনার NDK API স্তর আপনার ডিভাইস দ্বারা সমর্থিত API থেকে বেশি।

সমাধান : আপনার NDK API স্তর ( APP_PLATFORM ) সেট করুন আপনার অ্যাপটি সমর্থন করে এমন Android এর ন্যূনতম সংস্করণে।

সিস্টেম তৈরি করুন বিন্যাস
ndk-বিল্ড APP_PLATFORM
সিমেক ANDROID_PLATFORM
externalNativeBuild android.minSdkVersion

অন্যান্য বিল্ড সিস্টেমের জন্য, অন্যান্য বিল্ড সিস্টেমের সাথে NDK ব্যবহার করুন দেখুন।

__aeabi চিহ্নগুলি সনাক্ত করা যাচ্ছে না

নিম্নলিখিত বার্তা:

অসন্তুষ্ট লিঙ্ক ত্রুটি: dlopen ব্যর্থ হয়েছে: " __aeabi_memcpy " চিহ্ন সনাক্ত করতে পারে না

সম্ভাব্য রানটাইম ত্রুটির একটি উদাহরণ। আপনি যখন আপনার নেটিভ লাইব্রেরিগুলি লোড করার চেষ্টা করেন তখন এই ত্রুটিগুলি লগে উপস্থিত হয়৷ প্রতীকটি __aeabi_* ; __aeabi_memcpy এবং __aeabi_memclr সবচেয়ে সাধারণ বলে মনে হচ্ছে।

এই সমস্যাটি 126 ইস্যুতে নথিভুক্ত করা হয়েছে

প্রতীক rand সনাক্ত করতে পারে না

নিম্নলিখিত ত্রুটি লগ বার্তার জন্য:

অসন্তুষ্ট লিঙ্ক ত্রুটি: ডিলোপেন ব্যর্থ হয়েছে: " rand " চিহ্ন সনাক্ত করতে পারে না

এই বিস্তারিত স্ট্যাক ওভারফ্লো উত্তর দেখুন।

__atomic_*

সমস্যা : পারমাণবিক ক্রিয়াকলাপের জন্য কিছু বাস্তবায়ন প্রদানের জন্য কিছু ABI-এর libatomic প্রয়োজন।

সমাধান : লিঙ্ক করার সময় -latomic যোগ করুন।

নিম্নলিখিত ত্রুটি বার্তার জন্য:

ত্রুটি: ' __atomic_exchange_4 ' এর অনির্ধারিত রেফারেন্স

এখানে প্রকৃত প্রতীক __atomic_ এর সাথে উপসর্গযুক্ত কিছু হতে পারে।

RTTI/ব্যতিক্রম গ্রন্থাগারের সীমানা জুড়ে কাজ করছে না

সমস্যা : ভাগ করা লাইব্রেরি সীমানা জুড়ে নিক্ষিপ্ত হলে ব্যতিক্রম ধরা হচ্ছে না, বা dynamic_cast ব্যর্থ হচ্ছে।

সমাধান : আপনার প্রকারগুলিতে একটি কী ফাংশন যোগ করুন। একটি কী ফাংশন হল প্রথম অ-বিশুদ্ধ, একটি টাইপের জন্য আউট-অফ-লাইন ভার্চুয়াল ফাংশন। একটি উদাহরণের জন্য, ইস্যু 533 এর আলোচনা দেখুন।

C++ ABI বলে যে দুটি অবজেক্টের ধরন একই হলে এবং শুধুমাত্র যদি তাদের type_info পয়েন্টার অভিন্ন হয়। ক্যাচের জন্য type_info যদি ছোঁড়া ব্যতিক্রমের সাথে মেলে তবেই ব্যতিক্রম ধরা যেতে পারে। একই নিয়ম dynamic_cast এর জন্য প্রযোজ্য।

যখন একটি টাইপের একটি কী ফাংশন থাকে না, তখন তার typeinfo একটি দুর্বল প্রতীক হিসাবে নির্গত হয় এবং লাইব্রেরিগুলি লোড করার সময় মিলিত প্রকারের তথ্যগুলি একত্রিত হয়। এক্সিকিউটেবল লোড হওয়ার পরে লাইব্রেরিগুলিকে গতিশীলভাবে লোড করার সময় (অন্য কথায়, dlopen বা System.loadLibrary মাধ্যমে), লোডারের পক্ষে লোড করা লাইব্রেরির জন্য টাইপ ইনফো একত্রিত করা সম্ভব নাও হতে পারে। যখন এটি ঘটে, তখন দুটি প্রকারকে সমান হিসাবে বিবেচনা করা হয় না।

অমিল প্রিবিল্ট লাইব্রেরি ব্যবহার করা

প্রি-বিল্ট লাইব্রেরি ব্যবহার করা—এগুলি সাধারণত তৃতীয়-পক্ষের লাইব্রেরি—আপনার অ্যাপ্লিকেশনে একটু বাড়তি যত্নের প্রয়োজন। সাধারণভাবে, নিম্নলিখিত নিয়মগুলি সম্পর্কে সচেতন হন:

  • ফলস্বরূপ অ্যাপের ন্যূনতম API স্তরটি সমস্ত অ্যাপের লাইব্রেরির minSdkVersion s-এর সর্বোচ্চ।

    যদি আপনার minSdkVersion 16 হয়, কিন্তু আপনি একটি প্রি-বিল্ট লাইব্রেরি ব্যবহার করছেন যা 21-এর বিপরীতে তৈরি করা হয়েছিল, ফলস্বরূপ অ্যাপের ন্যূনতম API স্তর হল 21। এটি মেনে চলার ব্যর্থতা বিল্ড টাইমে দৃশ্যমান হবে যদি প্রি-বিল্ট লাইব্রেরি স্ট্যাটিক থাকে, কিন্তু নাও হতে পারে প্রিবিল্ট শেয়ার্ড লাইব্রেরির জন্য রান টাইম পর্যন্ত উপস্থিত হয়।

  • সমস্ত লাইব্রেরি একই NDK সংস্করণ দিয়ে তৈরি করা উচিত।

    এই নিয়মটি বেশিরভাগের তুলনায় একটু বেশি নমনীয় কারণ ভাঙ্গনগুলি বিরল, তবে NDK-এর বিভিন্ন প্রধান সংস্করণগুলির সাথে তৈরি করা লাইব্রেরির মধ্যে সামঞ্জস্যের নিশ্চয়তা নেই। C++ ABI স্থিতিশীল নয় এবং অতীতে পরিবর্তিত হয়েছে।

  • একাধিক ভাগ করা লাইব্রেরি সহ অ্যাপ্লিকেশনগুলিকে অবশ্যই একটি ভাগ করা STL ব্যবহার করতে হবে৷

    অসামঞ্জস্যপূর্ণ STLগুলির মতো, এর কারণে সৃষ্ট সমস্যাগুলি যদি খুব যত্ন নেওয়া হয় তবে এড়ানো যেতে পারে, তবে সমস্যাটি এড়ানো ভাল। এই সমস্যা এড়ানোর সর্বোত্তম উপায় হল আপনার অ্যাপে একাধিক শেয়ার করা লাইব্রেরি থাকা এড়ানো।