Deweloper oprogramowania przechodzący z systemu Linux na OS X, jakie są problemy?

Użyłem Ubuntu / Fedora / Red Hat / Suse, ale w ogóle nie używałem OS X. Jeśli muszę regularnie korzystać z systemu OS X, na co powinienem uważać?

Narzędzia, których używam to łańcuch narzędzi GNU, C ++ / Boost itp.

Zrobiłem ten sam ruch lata temu. Oto rzeczy, na które wpadłem:

• Przeciętny komputer stacjonarny z Linuksem ma bogatsze środowisko użytkownika niż system OS X.

  Prawdopodobnie będziesz tęsknił za innymi narzędziami niż ja, więc nie ma sensu sprecyzować zalecenia dotyczące zamienników.

  Zamiast tego po prostu zainstaluj Fink , MacPorts lub Homebrew . Systemy te zapewniają system zarządzania pakietami typowy dla Linuksa lub BSD. Każdy ma swój własny smak i zestaw opakowań, więc właściwy wybór będzie oparty na twoich gustach i potrzebach.

  Może się okazać, że żaden system pakietów nie będzie zawierał każdego programu, którego potrzebujesz. Niektóre programy nie zostały jeszcze przeniesione do systemu OS X, więc nie pojawią się w żadnym systemie pakietów. Niemniej jednak systemy te znacznie rozszerzają możliwości systemu OS X i ułatwiają przejście z systemu Linux.

• Kompilatory wiersza poleceń OS X domyślnie budują teraz 64-bitowe pliki wykonywalne.

  W systemie Leopard i wcześniejszych kompilatory domyślnie budowały 32-bitowe pliki wykonywalne. Może to powodować problemy na kilka sposobów: być może masz stare biblioteki 32-bitowe, których nie możesz odbudować, ale musisz się z nimi połączyć, być może nadal używasz systemu w trybie 32-bitowym itp.

  Jednym ze sposobów wymuszenia kompilacji 32-bitowej jest zastąpienie gccwartości domyślnych w systemach kompilacji, przy gcc-4.0czym jest to stary 32-bitowy domyślnie kompilator Leoparda. ( gccjest dowiązaniem symbolicznym do domyślnie 64-bitowych w systemie gcc-4.2Snow Leopard.) W systemach kompilacji opartych na autoconf działa to:

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

  ( CXXBit ten jest potrzebny tylko wtedy, gdy program zawiera komponenty C ++.)

  Innym sposobem jest przejście -m32do kompilatora i konsolidatora:

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

  To więcej pisania, ale pozwala uzyskać 32-bitowe wersje z nowszej wersji GCC.

• Połączenie dynamiczne jest zupełnie inne.

  Jeśli lubisz pisać ldpolecenia ręcznie, czas zerwać z tym nawykiem. Zamiast tego powinieneś łączyć programy i biblioteki za pomocą kompilatora lub używać pośrednika, takiego jak libtool. Zajmują się drobiazgowymi, specyficznymi dla platformy różnicami w linkach, dzięki czemu możesz zaoszczędzić energię mózgu na programy edukacyjne, których nie można oderwać od przenośnych mechanizmów.

  Na przykład musisz zaktualizować pamięć mięśni, aby otool -L someprogramzamiast pisać, ldd someprogramdowiedzieć się, z którymi bibliotekami someprogramjest powiązane, musisz pisać .

  Inną różnicą w dynamicznym łączeniu, która na początku obróci mózg, jest to, że w OS X lokalizacja instalacji biblioteki jest zapisywana w samej bibliotece , a linker kopiuje ją do pliku wykonywalnego w czasie łączenia. Oznacza to, że jeśli łączysz się z biblioteką, która została zainstalowana, /usr/local/libale chcesz wysłać ją do użytkowników w tym samym katalogu co plik wykonywalny, musisz powiedzieć coś takiego w ramach procesu instalacji:

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

  Teraz wiele z powyższych elementów może się różnić w zależności od systemu kompilacji, więc weź to jako przykład, a nie przepis. Powoduje to utworzenie prywatnej kopii biblioteki, z którą się łączy, zmienia identyfikator biblioteki współdzielonej ze ścieżki bezwzględnej na względną, co oznacza „w tym samym katalogu co plik wykonywalny”, a następnie wymusza przebudowę pliku wykonywalnego względem tej zmodyfikowanej kopii biblioteki.

  install_name_tooljest tutaj głównym poleceniem. Jeśli zamiast tego chciałbyś zainstalować bibliotekę w ../libkatalogu względem pliku wykonywalnego, -idargument musiałby być @loader_path/../lib/libfoo.dylibzamiast tego.

  Joe Di Pol napisał na ten temat dobry artykuł z dużo większą ilością szczegółów.

• Dynamiczne połączenie + pakiety stron trzecich mogą wcześnie powodować bóle głowy.

  Prawdopodobnie napotkasz problemy z dynamicznym łączeniem już na początku, jak tylko zaczniesz próbować używać bibliotek z pakietów innych firm, które nie instalują bibliotek w standardowych lokalizacjach. MacPorts robi to na przykład, instalując biblioteki /opt/local/libzamiast, /usr/liblub /usr/local/lib. Po napotkaniu tego problemu dobrym rozwiązaniem jest dodanie do swojego wiersza następujących wierszy .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 obsługuje problem ze zgodnością procesora inaczej niż Linux.

  W 64-bitowym systemie Linux, z którego musisz obsługiwać 32-bit, z dowolnego powodu powstają dwie kopie rzeczy, takich jak biblioteki, które muszą być w obu formatach, z wersjami 64-bitowymi w lib64katalogu równoległym do tradycyjny libkatalog.

  OS X rozwiązuje ten problem inaczej, dzięki koncepcji binarnej Universal, która pozwala umieścić wiele plików binarnych w jednym pliku. Obecnie możesz mieć pliki wykonywalne obsługujące do 4 typów procesorów: 32- i 64-bitowy procesor PowerPC oraz 32- i 64-bitowy procesor Intel.

  Łatwo jest budować uniwersalne pliki binarne za pomocą Xcode, ale trochę kłopotów z narzędziami wiersza poleceń. W ten sposób otrzymujesz wersję Universal Intel tylko z systemami kompilacji opartymi na Autoconf:

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

  Dodaj -arch ppc -arch ppc64do CFLAGSi LDFLAGSjeśli potrzebujesz wsparcia PowerPC.

  Jeśli nie wyłączysz śledzenia zależności, budujesz tylko na jednej platformie, ponieważ obecność nowo zbudowanych .oplików na pierwszej platformie przekonuje make(1), że nie trzeba też budować na drugiej platformie. Wszystko musi być zbudowane dwukrotnie w powyższym przykładzie; cztery razy dla w pełni uniwersalnego pliku binarnego, jeśli nadal potrzebujesz wsparcia PowerPC.

  (Więcej informacji w uwadze technicznej Apple TN2137 .)

• Narzędzia programistyczne nie są domyślnie instalowane w systemie OS X.

  Przed Lionem najbardziej niezawodnym miejscem na znalezienie odpowiednich narzędzi programistycznych dla twojego systemu były dyski z systemem operacyjnym. Są opcjonalną instalacją.

  Zaletą instalowania narzędzi programistycznych z dysków z systemem operacyjnym jest to, że wiesz, że narzędzia będą działać z systemem operacyjnym. Apple jako Apple, musisz mieć najnowszą wersję systemu operacyjnego, aby uruchomić najnowsze kompilatory, a oni nie zawsze udostępnili pobieranie starych narzędzi, więc dyski z systemem operacyjnym są często najłatwiejszym sposobem na znalezienie odpowiednich narzędzi dla danego dev lub test box.

  W przypadku Lion starają się zrezygnować z nośników instalacyjnych, więc jeśli nie kupisz drogiej wersji klucza USB, będziesz musiał pobrać Xcode z App Store .

  Polecam zachować przynajmniej kilka wersji dowolnych pobranych plików Xcode DMG. Kiedy następca Lion wyjdzie za rok lub trzy, możesz znaleźć się bez możliwości zainstalowania współczesnej wersji Xcode na testowej maszynie wirtualnej Lion. Planuj z wyprzedzeniem, na wypadek problemów z dostępnością i braku nośników systemu operacyjnego uniemożliwiających uzyskanie starych wersji Xcode.

OGROMNA GOTCHA - System plików Mac OS NIE rozróżnia wielkości liter.

Chociaż Fink i MacPorts są tradycyjnymi sposobami uzyskiwania pakietów uniksowych w systemie OS X, zaleciłbym sprawdzenie nowszego narzędzia o nazwie, brewktóre działało dla mnie lepiej i mniej pomieszało się z moim systemem i jest znacznie łatwiejsze w użyciu. Zasadniczo po prostu pobiera pliki archiwalne i instaluje się w / usr / local, ale bardzo ładnie automatyzuje cały proces.

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

OGROMNA GOTCHA - System plików Mac OS NIE rozróżnia wielkości liter.

W systemie Mac OS X można utworzyć obraz dysku uwzględniający wielkość liter, który można zamontować jako normalny wolumin dysku twardego.

# 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}"

Oto dobre źródło wybranych artykułów dla twórców, lista literatury kakao:

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

(Może to być szczególnie przydatne, jeśli pewnego dnia chcesz skorzystać z gadżetów specyficznych dla Mac OS X.)

Podczas przenoszenia stosu sieciowego z Solaris, BSD, Linux i Windows na OSX, jedynym głównym punktem, który zwraca uwagę, jest to, że podobnie jak FreeBSD cały łańcuch narzędzi jest dość stary.

Apple przyspiesza dzięki systemowi OSX Lion, ale Leopard i Snow Leopard stoją za nowoczesnymi dystrybucjami Linuksa i wiele standardów nie jest obsługiwanych. W moim przypadku uderza mnie brak RFC 3678 (rozszerzenia interfejsu gniazd dla filtrów źródła Multicast), który jest dość niewygodny.

Na serwerze OSX zainstalowałem system plików z rozróżnianiem wielkości liter, ponieważ zaleca się to zrobić w przypadku udostępniania HTTP.

• Old GCC
• Old Autoconf, Automake, libtool
• Brak blokad Pthread, OSX zapewnia natywne alternatywy.
• Niewiele ponownie API dzierżawionych NSS.
• Niezbyt przydatny /procsystem plików.
• Nie /dev/rtc, /dev/hpeti RDTSCwydaje się być wyćwiczony. OSX zapewnia natywne alternatywy.
• Nie epoll, ale masz polli kqueue

OS X obsługuje, pthread_cond_timedwaitale wykorzystuje bezwzględny czas kalendarzowy i nie ma sposobu na użycie monotonicznie rosnącego czasu.