Tôi đã thực hiện cùng một động thái nhiều năm trước. Dưới đây là những điều tôi gặp phải:
Linux máy tính để bàn trung bình của bạn có vùng người dùng phong phú hơn so với OS X.
Bạn có thể sẽ bỏ lỡ các công cụ khác nhau so với tôi đã làm, vì vậy sẽ không có ý nghĩa cụ thể về các đề xuất thay thế.
Thay vào đó, chỉ cần cài đặt Fink , MacPorts hoặc Homebrew trước tiên. Các hệ thống này cung cấp một hệ thống quản lý gói điển hình của Linux hoặc BSD. Mỗi loại có hương vị riêng và bộ gói, vì vậy sự lựa chọn đúng sẽ dựa trên thị hiếu và nhu cầu của bạn.
Bạn có thể thấy rằng không có một hệ thống gói nào có mọi chương trình bạn cần. Một số chương trình chưa được chuyển sang OS X, vì vậy chúng sẽ không xuất hiện trong bất kỳ hệ thống gói nào . Tuy nhiên, các hệ thống này thực sự mở rộng đáng kể những gì được cung cấp với OS X và sẽ giúp bạn dễ dàng chuyển đổi từ Linux.
Trình biên dịch dòng lệnh OS X hiện xây dựng các tệp thực thi 64 bit theo mặc định.
Thay vào đó, trong Leopard và các trình biên dịch đã xây dựng các tệp thực thi 32 bit theo mặc định. Điều này có thể gây ra sự cố theo nhiều cách: có thể bạn có các thư viện 32 bit cũ mà bạn không thể xây dựng lại nhưng phải liên kết đến, có thể bạn vẫn đang chạy hệ thống của mình ở chế độ 32 bit, v.v.
Một cách để buộc xây dựng 32 bit là ghi đè gccmặc định trong các hệ thống xây dựng gcc-4.0, đó là trình biên dịch Leopard 32 bit theo mặc định cũ. ( gcclà một liên kết tượng trưng đến 64 bit theo mặc định gcc-4.2trên Snow Leopard.) Với các hệ thống xây dựng dựa trên autoconf, điều này hoạt động:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Bạn chỉ cần CXXbit nếu chương trình chứa các thành phần C ++.)
Một cách khác là chuyển -m32đến trình biên dịch và trình liên kết:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Nó gõ nhiều hơn, nhưng nó cho phép bạn có các bản dựng 32 bit từ GCC mới hơn.
Liên kết động là rất khác nhau.
Nếu bạn là người thích viết các ldlệnh của mình bằng tay, đã đến lúc bỏ thói quen đó. Thay vào đó, bạn nên liên kết các chương trình và thư viện thông qua trình biên dịch hoặc sử dụng một trung gian như libtool. Chúng quan tâm đến sự khác biệt của sơ đồ liên kết nền tảng cụ thể, vì vậy bạn có thể tiết kiệm năng lượng cho các chương trình học mà bạn không thể trừu tượng hóa bằng các cơ chế di động.
Chẳng hạn, bạn sẽ cần cập nhật bộ nhớ cơ để bạn nhập otool -L someprogramthay vì ldd someprogramtìm ra thư viện nào someprogramđược liên kết.
Một sự khác biệt khác trong liên kết động lúc đầu sẽ xoắn não bạn là trên OS X, vị trí cài đặt cho thư viện được ghi lại trong chính thư viện và trình liên kết sao chép vào tệp thực thi tại thời điểm liên kết. Điều này có nghĩa là nếu bạn liên kết đến một thư viện đã được cài đặt /usr/local/libnhưng bạn muốn gửi nó cho người dùng của mình trong cùng thư mục với tệp thực thi, bạn cần nói một cái gì đó như thế này như là một phần của quá trình cài đặt của bạn:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Bây giờ, phần lớn những điều trên có thể thay đổi cho hệ thống xây dựng của bạn, vì vậy chỉ lấy nó làm ví dụ, thay vì công thức. Điều này làm cho một bản sao riêng của thư viện mà chúng ta liên kết đến, thay đổi định danh thư viện dùng chung từ một đường dẫn tuyệt đối thành một nghĩa tương đối "trong cùng thư mục với tệp thực thi", sau đó buộc xây dựng lại tệp thực thi đối với bản sao đã sửa đổi này của thư viện.
install_name_toollà lệnh cốt lõi ở đây. Nếu thay vào đó, bạn muốn cài đặt thư viện trong một ../libthư mục liên quan đến tệp thực thi, thì -idđối số sẽ cần phải được @loader_path/../lib/libfoo.dylibthay thế.
Joe Di Pol đã viết một bài viết hay về điều này , với nhiều chi tiết hơn.
Liên kết động + gói bên thứ ba có thể gây đau đầu sớm.
Bạn có thể sớm gặp phải các vấn đề liên kết động, ngay khi bạn bắt đầu thử sử dụng các thư viện từ các gói của bên thứ ba không cài đặt các thư viện vào các vị trí tiêu chuẩn. MacPorts thực hiện việc này, ví dụ, cài đặt thư viện vào /opt/local/lib, chứ không phải /usr/libhoặc /usr/local/lib. Khi bạn gặp phải vấn đề này, một cách khắc phục tốt cho vấn đề là thêm các dòng như sau vào .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 xử lý vấn đề tương thích CPU khác với Linux.
Trên Linux 64 bit, bạn cũng phải hỗ trợ 32 bit vì bất kỳ lý do gì, bạn kết thúc với hai bản sao của các thư viện cần ở cả hai định dạng, với các phiên bản 64 bit tắt trong một lib64thư mục song song với libthư mục truyền thống .
OS X giải quyết vấn đề này theo cách khác, với khái niệm nhị phân phổ quát, cho phép bạn đặt nhiều tệp nhị phân vào một tệp. Hiện tại bạn có thể có các tệp thực thi hỗ trợ tối đa 4 loại CPU: PowerPC 32 và 64 bit, cộng với Intel 32 và 64 bit.
Thật dễ dàng để xây dựng các nhị phân phổ quát với Xcode, nhưng hơi khó khăn với các công cụ dòng lệnh. Điều này giúp bạn có bản dựng chỉ dành cho Intel với các hệ thống xây dựng dựa trên Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Thêm -arch ppc -arch ppc64vào CFLAGSvà LDFLAGSnếu bạn cần hỗ trợ PowerPC.
Nếu bạn không tắt theo dõi phụ thuộc, cuối cùng bạn chỉ xây dựng cho một nền tảng, vì sự hiện diện của .ocác tệp được xây dựng mới cho nền tảng đầu tiên cũng thuyết phục make(1)rằng nó cũng không cần phải xây dựng cho nền tảng thứ hai. Tất cả mọi thứ phải được xây dựng hai lần trong ví dụ trên; bốn lần cho một nhị phân hoàn toàn phổ quát, nếu bạn vẫn cần hỗ trợ PowerPC.
(Thông tin thêm trong Ghi chú kỹ thuật của Apple TN2137 .)
Các công cụ dành cho nhà phát triển không được cài đặt trên OS X theo mặc định.
Trước Lion, nơi đáng tin cậy nhất để có được các công cụ phát triển phù hợp cho hệ thống của bạn là trên các đĩa hệ điều hành. Chúng là một cài đặt tùy chọn.
Điều tuyệt vời khi cài đặt các công cụ dev từ các đĩa hệ điều hành là bạn biết các công cụ này sẽ hoạt động với HĐH. Apple là Apple, bạn phải có một phiên bản HĐH gần đây để chạy các trình biên dịch mới nhất và họ luôn không tải xuống các công cụ cũ, vì vậy các đĩa OS thường là cách dễ nhất để tìm các công cụ phù hợp cho một công cụ nhất định dev hoặc hộp kiểm tra.
Với Lion, họ đang cố gắng loại bỏ phương tiện cài đặt, vì vậy trừ khi bạn mua phiên bản khóa USB đắt tiền, bạn sẽ phải tải xuống Xcode từ App Store .
Tôi khuyên bạn nên giữ ít nhất một vài phiên bản của bất kỳ DMG Xcode nào bạn tải xuống. Do đó, khi người kế nhiệm của Lion ra mắt một hoặc ba năm, bạn có thể thấy mình không có cách nào để cài đặt phiên bản Xcode đương thời trên máy ảo Lion thử nghiệm. Lập kế hoạch trước trong trường hợp các vấn đề về tính khả dụng và thiếu phương tiện hệ điều hành làm cho các phiên bản Xcode cũ không thể lấy được.