นักพัฒนาซอฟต์แวร์เปลี่ยนจาก Linux เป็น OS X gotchas คืออะไร

ฉันใช้ Ubuntu / Fedora / Red Hat / Suse แล้วแต่ไม่ได้ใช้ OS X เลย หากฉันต้องเริ่มใช้ OS X เป็นประจำสิ่งที่ควรระวังคืออะไร

เครื่องมือที่ฉันใช้คือ GNU tool chain, C ++ / Boost, เป็นต้น

ฉันทำแบบเดียวกันหลายปีที่ผ่านมา นี่คือสิ่งที่ฉันพบ:

• เดสก์ท็อปเฉลี่ยของคุณมี userland ที่สมบูรณ์ยิ่งกว่า OS X

  คุณอาจพลาดเครื่องมือที่แตกต่างไปจากที่เคยทำดังนั้นจึงไม่มีความรู้สึกที่เจาะจงเกี่ยวกับคำแนะนำสำหรับการเปลี่ยน

  ให้ติดตั้งFink , MacPortsหรือHomebrewแทน ระบบเหล่านี้มีระบบการจัดการบรรจุภัณฑ์ตามแบบฉบับของ Linux หรือ BSD แต่ละชุดมีชุดของตัวเองและรสชาติดังนั้นทางเลือกที่เหมาะสมจะขึ้นอยู่กับรสนิยมและความต้องการของคุณ

  คุณอาจพบว่าไม่มีระบบแพ็คเกจใดที่จะมีทุกโปรแกรมที่คุณต้องการ บางโปรแกรมยังไม่ได้รับการย้ายไปยัง OS X ดังนั้นจึงไม่ปรากฏในระบบแพ็คเกจใด ๆ อย่างไรก็ตามระบบเหล่านี้จะขยายสิ่งที่มาพร้อมกับ OS X อย่างมากและจะช่วยให้การเปลี่ยนจาก Linux เป็นไปอย่างง่ายดาย

• ตอนนี้คอมไพเลอร์บรรทัดคำสั่งของ OS X จะสร้างไฟล์เรียกทำงาน 64 บิตโดยค่าเริ่มต้น

  ใน Leopard และก่อนหน้าคอมไพเลอร์ได้สร้างโปรแกรมปฏิบัติการ 32- บิตโดยค่าเริ่มต้นแทน สิ่งนี้อาจทำให้เกิดปัญหาได้หลายวิธี: บางทีคุณอาจมีไลบรารี่แบบ 32 บิตเก่าที่คุณไม่สามารถสร้างใหม่ได้ แต่ต้องเชื่อมโยงกับคุณอาจจะยังคงใช้ระบบของคุณในโหมด 32 บิตเป็นต้น

  วิธีหนึ่งในการบังคับให้บิวด์ 32- บิตคือการแทนที่gccค่าปริยายในระบบบิลด์ด้วยgcc-4.0ซึ่งเป็นคอมไพเลอร์ Leopard แบบ 32 บิตโดยปริยาย ( gccเป็น symlink ของ 64 บิตโดยปริยายgcc-4.2บน Snow Leopard) ด้วยระบบการสร้างแบบ autoconf สิ่งนี้จะทำงาน:

  $ ./configure CC=gcc-4.0 CXX=g++-4.0
  

  (คุณต้องการเพียงCXXบิตถ้าโปรแกรมมีส่วนประกอบ C ++)

  อีกวิธีคือส่งผ่าน-m32ไปยังคอมไพเลอร์และลิงเกอร์:

  $ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
  

  มันเป็นเรื่องที่พิมพ์ได้มากกว่า แต่มันทำให้คุณสามารถสร้าง 32- บิตจาก GCC ที่ใหม่กว่าได้

• การเชื่อมโยงแบบไดนามิกนั้นแตกต่างกันอย่างมากมาย

  หากคุณเป็นคนชอบเขียนldคำสั่งด้วยมือก็ถึงเวลาที่คุณจะเลิกนิสัยนี้ libtoolคุณควรจะแทนการเชื่อมโยงโปรแกรมและห้องสมุดผ่านคอมไพเลอร์หรือใช้ตัวกลางเช่น สิ่งเหล่านี้จะดูแลความแตกต่างของรูปแบบการเชื่อมโยงเฉพาะแพลตฟอร์ม niggly ดังนั้นคุณสามารถประหยัดพลังสมองสำหรับโปรแกรมการเรียนรู้ที่คุณไม่สามารถแยกออกได้ด้วยกลไกแบบพกพา

  ตัวอย่างเช่นคุณจะต้องอัปเดตหน่วยความจำของกล้ามเนื้อของคุณเพื่อให้คุณพิมพ์otool -L someprogramแทนที่จะldd someprogramคิดออกว่าห้องสมุดsomeprogramใดที่เชื่อมโยงกับ

  ความแตกต่างอีกในการเชื่อมโยงแบบไดนามิกที่จะบิดสมองของคุณในตอนแรกก็คือว่าใน OS X ที่สถานที่ติดตั้งสำหรับห้องสมุดจะถูกบันทึกไว้ในห้องสมุดของตัวเองและสำเนาลิงเกอร์ที่เข้าปฏิบัติการในเวลาที่การเชื่อมโยง ซึ่งหมายความว่าหากคุณเชื่อมโยงไปยังไลบรารีที่ติดตั้งไว้/usr/local/libแต่คุณต้องการจัดส่งไปยังผู้ใช้ของคุณในไดเรกทอรีเดียวกับไฟล์ที่เรียกใช้งานได้คุณต้องพูดสิ่งนี้เป็นส่วนหนึ่งของกระบวนการติดตั้งของคุณ:

  $ cp /usr/local/lib/libfoo.dylib .
  $ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
  $ make LDFLAGS=-L. relink
  

  ตอนนี้สิ่งต่าง ๆ ที่กล่าวมาส่วนใหญ่มีความแตกต่างกันไปตามระบบการสร้างของคุณดังนั้นให้ลองใช้มันเป็นตัวอย่างแทนที่จะเป็นสูตร สิ่งนี้ทำให้สำเนาส่วนตัวของไลบรารีที่เราเชื่อมโยงเปลี่ยนตัวระบุไลบรารีที่แบ่งใช้จากพา ธ สัมบูรณ์เป็นสัมพัทธ์หนึ่งความหมาย "ในไดเรกทอรีเดียวกันกับไฟล์ปฏิบัติการ" จากนั้นบังคับให้สร้างไฟล์ปฏิบัติการที่เรียกคืนได้จากสำเนาที่แก้ไขนี้ ของห้องสมุด

  install_name_toolเป็นคำสั่งหลักที่นี่ หากคุณต้องการติดตั้งไลบรารีใน../libไดเรกทอรีที่สัมพันธ์กับไฟล์ที่เรียกใช้งานได้-idอาร์กิวเมนต์จะต้องถูก@loader_path/../lib/libfoo.dylibแทนที่แทน

  Joe Di Pol เขียนบทความที่ดีเกี่ยวกับเรื่องนี้โดยมีรายละเอียดมากขึ้น

• การเชื่อมโยงแบบไดนามิก + แพ็คเกจของบุคคลที่สามอาจทำให้เกิดอาการปวดหัวในช่วงต้น

  คุณมีแนวโน้มที่จะพบปัญหาการเชื่อมโยงแบบไดนามิกในช่วงต้นของการเริ่มต้นทันทีที่คุณเริ่มพยายามใช้ไลบรารีจากแพ็คเกจของบุคคลที่สามที่ไม่ได้ติดตั้งไลบรารีลงในตำแหน่งที่ตั้งมาตรฐาน MacPortsไม่นี้ตัวอย่างเช่นการติดตั้งเข้าไปในห้องสมุด/opt/local/libมากกว่าหรือ/usr/lib /usr/local/libเมื่อคุณพบปัญหานี้การแก้ไขปัญหาที่ดีคือการเพิ่มบรรทัดดังต่อไปนี้ใน.bash_profile:

  # Tell the dynamic linker (dyld) where to find MacPorts package libs
  export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH
  
  # Add MacPorts header file install dirs to your gcc and g++ include paths
  export C_INCLUDE_PATH=/opt/local/include:$C_INCLUDE_PATH
  export CPLUS_INCLUDE_PATH=/opt/local/include:$CPLUS_INCLUDE_PATH
  

• OS X จัดการปัญหาความเข้ากันได้ของ CPU แตกต่างจาก Linux

  บน Linux 64- บิตที่คุณต้องรองรับ 32- บิตไม่ว่าด้วยเหตุผลใดคุณจะพบกับสองสำเนาของสิ่งต่าง ๆ เช่นไลบรารี่ที่จำเป็นต้องอยู่ในทั้งสองรูปแบบโดยที่เวอร์ชั่น 64 บิตในlib64ไดเรกทอรีจะขนานกับlibไดเรกทอรีดั้งเดิม

  OS X แก้ปัญหานี้แตกต่างกันด้วยแนวคิดไบนารีสากลซึ่งช่วยให้คุณใส่ไบนารีหลายรายการไว้ในไฟล์เดียว ขณะนี้คุณสามารถมีไฟล์เรียกทำงานที่รองรับ CPU ได้มากถึง 4 ชนิด: PowerPC 32- และ 64- บิตรวมถึง Intel 32- และ 64- บิต

  เป็นเรื่องง่ายที่จะสร้าง Universal ไบนารีด้วย Xcode แต่มีปัญหาเล็กน้อยกับเครื่องมือบรรทัดคำสั่ง สิ่งนี้จะช่วยให้คุณสร้าง Universal Universal เท่านั้นสำหรับสร้างด้วยระบบสร้างอัตโนมัติที่ใช้ Autoconf:

  $ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
    LDFLAGS='-arch i386 -arch x86_64'
  

  เพิ่ม-arch ppc -arch ppc64ไปยังCFLAGSและLDFLAGSหากคุณต้องการการสนับสนุน PowerPC

  หากคุณไม่ได้ปิดการใช้งานการติดตามการพึ่งพาคุณจะสร้างเพียงหนึ่งแพลตฟอร์มเนื่องจากการมี.oไฟล์ที่สร้างขึ้นใหม่สำหรับแพลตฟอร์มแรกทำให้มั่นใจได้make(1)ว่ามันไม่จำเป็นต้องสร้างสำหรับแพลตฟอร์มที่สองเช่นกัน ทุกอย่างต้องถูกสร้างขึ้นสองครั้งในตัวอย่างด้านบน สี่ครั้งสำหรับไบนารีครบวงจรหากคุณยังต้องการการสนับสนุน PowerPC

  (ข้อมูลเพิ่มเติมในApple Technical Note TN2137 )

• เครื่องมือของนักพัฒนาซอฟต์แวร์จะไม่ถูกติดตั้งบน OS X โดยค่าเริ่มต้น

  ก่อนที่ Lion จะเป็นสถานที่ที่น่าเชื่อถือที่สุดในการรับเครื่องมือ dev ที่เหมาะสมสำหรับระบบของคุณอยู่ในดิสก์ระบบปฏิบัติการ เป็นการติดตั้งเสริม

  สิ่งที่ดีเกี่ยวกับการติดตั้งเครื่องมือ dev จากแผ่นดิสก์ระบบปฏิบัติการคือคุณรู้ว่าเครื่องมือจะทำงานกับระบบปฏิบัติการ Apple เป็น Apple คุณต้องมีระบบปฏิบัติการเวอร์ชันล่าสุดเพื่อใช้งานคอมไพเลอร์ล่าสุดและพวกเขาไม่ได้ทำการดาวน์โหลดเครื่องมือเก่า ๆ เสมอไปดังนั้นแผ่นดิสก์ระบบปฏิบัติการมักเป็นวิธีที่ง่ายที่สุดในการค้นหาเครื่องมือที่เหมาะสม dev หรือกล่องทดสอบ

  กับสิงโตที่พวกเขากำลังพยายามที่จะทำไปด้วยการติดตั้งสื่อดังนั้นถ้าคุณซื้อรุ่น USB สำคัญราคาแพงคุณจะต้องดาวน์โหลด Xcode จาก App Store

  ฉันแนะนำให้คุณเก็บ Xcode DMGs อย่างน้อยสองสามเวอร์ชันที่คุณดาวน์โหลด เมื่อผู้สืบทอดของ Lion ออกมาหนึ่งหรือสามปีดังนั้นคุณอาจพบว่าตัวเองไม่มีทางที่จะติดตั้ง Xcode รุ่นที่เกิดขึ้นพร้อมกันบน Lion test VM วางแผนล่วงหน้าในกรณีที่ปัญหาความพร้อมใช้งานและการไม่มีสื่อ OS ทำให้ Xcode เวอร์ชันเก่าไม่สามารถหาได้

ขนาดใหญ่ GOTCHA - ระบบไฟล์ Mac OS ไม่คำนึงถึงขนาดตัวพิมพ์

แม้ว่า Fink และ MacPorts เป็นวิธีการดั้งเดิมในการรับ Unix แพ็คเกจบน OS X แต่ฉันขอแนะนำให้ตรวจสอบเครื่องมือใหม่ที่เรียกbrewว่าใช้งานได้ดีกว่าสำหรับฉันและใช้งานระบบน้อยลงและใช้งานง่ายขึ้น มันเป็นเพียงแค่ดาวน์โหลด tarballs และติดตั้งไปยัง / usr / local แต่มันทำให้กระบวนการทั้งหมดเป็นไปอย่างอัตโนมัติ

http://mxcl.github.com/homebrew/

ขนาดใหญ่ GOTCHA - ระบบไฟล์ Mac OS ไม่คำนึงถึงขนาดตัวพิมพ์

คุณสามารถสร้างอิมเมจดิสก์แบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ใน Mac OS X ซึ่งสามารถติดตั้งเป็นไดรฟ์ข้อมูลฮาร์ดไดรฟ์ปกติ

# cf. http://codesnippets.joyent.com/posts/show/8617
IMAGE="${HOME}/Desktop/Case Sensitive Test.dmg"
VOLNAME="Case Sensitive Test"

hdiutil create "${IMAGE}" -size 10m -fs HFSX -volname "${VOLNAME}" -layout NONE

hdiutil attach "${IMAGE}"

cd "/Volumes/${VOLNAME}"
touch foo.txt Foo.txt
open .
ls -l [Ff]oo.txt
stat -f "inode: %i  --  name: %N" [Ff]oo.txt

cd ~
hdiutil detach "/Volumes/${VOLNAME}"

นี่คือแหล่งข้อมูลที่ดีของบทความ dev ที่เลือกรายชื่อวรรณกรรมโกโก้:

http://osx.hyperjeff.net/Reference/CocoaArticles

(สิ่งนี้อาจมีประโยชน์โดยเฉพาะอย่างยิ่งถ้าวันหนึ่งคุณต้องการใช้ประโยชน์จากสินค้าเฉพาะของ Mac OS X)

เมื่อทำการย้ายพอร์ตสแต็กเครือข่ายจาก Solaris, BSD, Linux และ Windows ไปยัง OSX จุดสำคัญเพียงข้อเดียวที่ได้รับความสนใจคือ FreeBSD นั้นโซ่เครื่องมือทั้งหมดค่อนข้างเก่า

Apple กำลังเร่งใช้กับ OSX Lion แต่ Leopard, Snow Leopard นั้นค่อนข้างล้าหลัง Linux รุ่นใหม่และไม่รองรับมาตรฐานหลายอย่าง ในกรณีของฉันฉันได้รับผลกระทบจากการขาดRFC 3678 (ส่วนต่อประสานซ็อกเก็ตส่วนต่อขยายสำหรับตัวกรอง Multicast Source) ซึ่งค่อนข้างไม่สะดวก

บนเซิร์ฟเวอร์ OSX ฉันได้ติดตั้งระบบไฟล์แบบตรงตามตัวพิมพ์เล็ก - ใหญ่เนื่องจากแนะนำให้ทำเช่นนั้นสำหรับการให้บริการ HTTP

• GCC เก่า
• Old Autoconf, Automake, libtool
• ไม่มีสปินล็อค Pthread OSX ให้ทางเลือกพื้นฐาน
• มี NSS API ที่ให้เช่าซ้ำไม่มาก
• /procระบบไฟล์ไม่ได้มีประโยชน์มากเกินไป
• ไม่มี/dev/rtc, /dev/hpetและRDTSCดูเหมือนว่าจะ gimped OSX มีทางเลือกอื่น ๆ
• ไม่epollแต่คุณมีpollและ kqueue

รองรับ OS X pthread_cond_timedwaitแต่ใช้เวลาปฏิทินแบบสัมบูรณ์และไม่มีวิธีใช้เวลาเพิ่มขึ้นแบบซ้ำซากจำเจ