رموز OSX / داروين لم تحام عند ربط الوظائف من

Question

أنا بصدد تشغيل مشروع كبير (~ 1 متر مربع) من بيئة نافذة / مرئية استوديو إلى منصات أخرى، أول منها يحدث أن يكون Mac OS X.

في الأصل تم تكوين المشروع كحلول ومشاريع Visual Studio، ولكن الآن أستخدم (الممتاز) -http://industriensone.com/premake.) لتوليد ملفات المشروع منصات متعددة (VS، XCode، Gmake).

لقد قمت بتكوينها، واستقلت وصنعت المشاريع القليلة الأولى دون أي مشاكل كبيرة، ولكن بعد أن قامت بتنفيذ Lib الرياضيات، هربت إلى هذا الخطأ الغريب الذي لم أتمكن من حله: أي وظائف تستخدم من الرياضيات سوف تفشل في الارتباط (تسبب الرموز التي لم يتم حلها).

للمرجع، أنا أستخدم Premake V4.2.1 لإنشاء مشاريع XCODE V3.2.1، وهو المبنى باستخدام GCC V4.2 بنية X86_64. (كل هذا على ليوبارد سنو 64 بت) حاولت إقناع دول مجلس التعاون الخليجي بربط وإنشاء كل شيء مقابل "معروف" SDK عن طريق إضافة -Insroot /developer/sdks/macosx10.6.sdk -mmacosx-version-min = 10.6 إلى سطر الأوامر بناء.

الآن في ظل الظروف العادية، يجب أن تهتم -lm في داروين، ومع ذلك في داروين، يتم تضمين هؤلاء الرياضيات في نظام LibSystem، والتي، والتي، بقدر ما أستطيع أن أقول، مرتبطة ضمنيا ب GCC / LD.

لقد حاولت إنشاء مشروع دمية من داخل Xcode الذي يعمل فقط:

float f = log2(2.0)+log2f(3.f)+log1p(1.1)+log1pf(1.2f)+sin(8.0);
std::cout << f << std::endl;

وكما هو متوقع، فإن هذا يبني جيدا. ومع ذلك، إذا وضعت نفس الشيء في التعليمات البرمجية داخل المشروع الذي تم إنشاؤه مسبقا، فإن جميع وظائف الرياضيات هذه تنتهي دون حل.

الآن مقارنة أمر الارتباط من مشروع XCode الأصلي مع مشروع Xcode الذي تم إنشاؤه، يبدو متطابقا جدا (إلا أن مشروعي الذي تم إنشاؤه يربط Libs الأخرى أيضا).

مشروع "الأصل":

/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -isysroot /Developer/SDKs/MacOSX10.6.sdk -Lsomepath -Fsomepath -filelist somefile -install_name somename -mmacosx-version-min=10.6 -single_module -compatibility_version 1 -current_version 1 -o somename

مشروع تم إنشاؤه:

/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -Lsomepath -Fsomepath -filelist somefile -install_name somename -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 somelib.a somelib2.a somelib.dylib somelib2.dylib -single_module -compatibility_version 1 -current_version 1 -o somename

أي مساعدة أو تلميحات حول كيفية المتابعة سيكون موضع تقدير أكثر. هل هناك أي أعلام دول مجلس التعاون الخليجي أو أدوات أخرى يمكن أن تساعدني في حل هذا؟

Answer 1

وأخيرا تمكنت من حل / العمل حول هذا الموضوع.

بتعويض

#include <math.h>
float f = sinf(1.f);

مع

#include <cmath>
float f = std::sin(1.f);

كل شيء يرتبط كما هو متوقع.

سأقبل حقيقة أن محلول CMATH هو الكود الذي يجب أن كتبته في المقام الأول، على الرغم من أنني أقبل بسعادة المزيد من الآراء حول سبب فشل نهج C بائسة كبيرة.