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.