LinuxからOS Xに切り替えるソフトウェア開発者、落とし穴は何ですか？

Ubuntu / Fedora / Red Hat / Suseを使用しましたが、OS Xはまったく使用していません。OS Xの使用を定期的に開始する必要がある場合、注意すべき点は何ですか？

使用するツールは、GNUツールチェーン、C ++ / Boostなどです。

何年も前に同じ動きをしました。私が遭遇したことは次のとおりです。

• あなたの平均的なデスクトップLinuxは、OS Xよりもリッチなユーザーランドを持っています。

  おそらく私とは異なるツールを見逃すことになるので、交換の推奨事項について具体的に説明する意味はありません。

  代わりに、Fink、MacPorts、またはHomebrewを最初にインストールするだけです。これらのシステムは、LinuxまたはBSDに典型的なパッケージ管理システムを提供します。それぞれが独自のフレーバーとパッケージセットを持っているので、正しい選択はあなたの好みとニーズに基づいて決まります。

  1つのパッケージシステムに必要なすべてのプログラムがあるわけではないことがあります。一部のプログラムはまだ持っている彼らは表示されませんので、OS Xに移植されるように任意のパッケージシステム。それでも、これらのシステムはOS Xに同梱されているものを大幅に拡張し、Linuxからの移行を容易にします。

• OS Xコマンドラインコンパイラは、デフォルトで64ビット実行可能ファイルをビルドするようになりました。

  Leopard以前では、コンパイラはデフォルトで32ビットの実行可能ファイルをビルドしました。これにより、いくつかの方法で問題が発生する可能性があります：再構築できないがリンクする必要がある古い32ビットライブラリがある場合、システムを32ビットモードで実行している場合など。

  32ビットビルドを強制する1つの方法はgcc、ビルドシステムのデフォルトを、デフォルトgcc-4.0の古い32ビットのLeopardコンパイラーでオーバーライドすることです。（Snow Leopardのgccデフォルトの64ビットへのシンボリックリンクですgcc-4.2。）autoconfベースのビルドシステムでは、これは機能します。

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

  （CXXプログラムにC ++コンポーネントが含まれている場合にのみビットが必要です。）

  別の方法は-m32、コンパイラとリンカに渡すことです：

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

  より多くの入力ができますが、新しいGCCから32ビットビルドを取得できます。

• 動的リンケージは大きく異なります。

  あなたが自分でldコマンドを書くのが好きなら、その習慣を打破する時が来ました。代わりに、コンパイラを介してプログラムやライブラリをリンクするか、のような中間体を使用する必要がありlibtoolます。これらはプラットフォーム固有のリンクスキームの違いを処理するので、ポータブルメカニズムでは抽象化できない学習プログラムの頭脳を節約できます。

  たとえば、どのライブラリがリンクされているかを調べるのではotool -L someprogramなく、入力するためにマッスルメモリを更新する必要があります。ldd someprogramsomeprogram

  最初に頭をひねる動的リンクのもう1つの違いは、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とは異なる方法で処理します。

  何らかの理由で32ビットもサポートする必要がある64ビットLinuxでは、両方の形式である必要があるライブラリなどのコピーが2つあり、64ビットバージョンはlib64ディレクトリと並行してオフになっています従来のlibディレクトリ。

  OS Xは、ユニバーサルバイナリコンセプトにより、この問題を異なる方法で解決します。これにより、複数のバイナリを1つのファイルに入れることができます。現在、最大4つのCPUタイプをサポートする実行可能ファイルを使用できます。32ビットおよび64ビットのPowerPCと、32ビットおよび64ビットのIntelです。

  Xcodeを使用してユニバーサルバイナリを作成するのは簡単ですが、コマンドラインツールでは少し苦労します。これにより、Autoconfベースのビルドシステムを使用したユニバーサルIntel専用ビルドが得られます。

  $ ./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)するため、2番目のプラットフォーム用にもビルドする必要がないと確信できるため、最終的に1つのプラットフォーム用にビルドします。上記の例では、すべてを2回作成する必要があります。PowerPCサポートが必要な場合は、完全にユニバーサルなバイナリの場合は4回。

  （詳細については、Apple Technical Note TN2137をご覧ください。）

• 開発者ツールはデフォルトでOS Xにインストールされていません。

  Lionの前は、システムに最適な開発ツールを入手するための最も信頼できる場所はOSディスクにありました。オプションのインストールです。

  OSディスクから開発ツールをインストールする利点は、OSでツールが機能することを知っていることです。AppleはAppleであるため、最新のコンパイラを実行するには最新バージョンのOSが必要です。また、古いツールのダウンロードを常に利用できるとは限らないため、OSディスクは特定のツールに適したツールを見つける最も簡単な方法です。 devまたはテストボックス。

  Lionでは、インストールメディアを廃止しようとしているため、高価なUSBキーバージョンを購入しない限り、App StoreからXcodeをダウンロードする必要があります。

  ダウンロードしたXcode DMGの少なくともいくつかのバージョンを保持することをお勧めします。そのため、Lionの後継者が1、3年で登場すると、LionテストVMに同時バージョンのXcodeをインストールする方法がないことに気付くかもしれません。可用性の問題とOSメディアの不足により古いバージョンのXcodeが入手できない場合は、事前に計画してください。

巨大なゴッチャ-Mac OSファイルシステムは大文字と小文字を区別しません。

FinkとMacPortsはOS XでUnixパッケージを取得する従来の手段ですがbrew、私にとってはより良く機能し、システムの操作が少なく、使いやすい新しいツールをチェックすることをお勧めします。基本的にはtarballをダウンロードして/ usr / localにインストールするだけですが、プロセス全体を非常にうまく自動化します。

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

巨大なゴッチャ-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}"

以下は、選択された開発者向け記事の良いソースであるCocoa文献リストです。

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

（これは、いつかMac OS X固有の機能を利用したい場合に特に便利です。）

ネットワークスタックをSolaris、BSD、Linux、およびWindowsからOSXに移植する場合、注目を集める唯一の主なポイントは、FreeBSDのようにツールチェーン全体がかなり古いことです。

AppleはOSX Lionでスピードアップしていますが、Leopard、Snow Leopardは最新のLinuxディストリビューションのかなり後ろにあり、多くの標準はサポートされていません。私の場合、RFC 3678（マルチキャストソースフィルター用のソケットインターフェイス拡張）が非常に不便であることに悩まされています。

OSXサーバーには、HTTPサービング用に大文字と小文字を区別するファイルシステムをインストールすることを推奨しているため、インストールしました。

• 古いGCC
• 古いAutoconf、Automake、libtool
• Pthreadスピンロックはありません。OSXはネイティブの代替を提供します。
• 多くの再レンタルNSS API。
• あまり便利ではない/procファイルシステム。
• ノー/dev/rtc、/dev/hpetとRDTSC笹縁ているように見えます。OSXはネイティブの代替を提供します。
• いいえepoll、しかしあなたはpollkqueue を持っています

OS Xはサポートしてpthread_cond_timedwaitいますが、カレンダーの絶対時間を使用しており、単調に増加する時間を使用する方法はありません。