web-dev-qa-db-ja.com

ソフトウェア開発者がLinuxからOS Xに切り替えた場合、問題点は何ですか？

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

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

linuxosx
51
grokus

私は何年も前に同じ動きをしました。これが私が遭遇したものです：

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

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

    代わりに、まず Fink 、 MacPorts 、または Homebrew をインストールしてください。これらのシステムは、LinuxまたはBSDに典型的なパッケージ管理システムを提供します。それぞれに独自のフレーバーとパッケージセットがあるため、適切な選択はユーザーの好みとニーズに基づいて行われます。

    必要なすべてのプログラムが1つのパッケージシステムにはない場合があります。一部のプログラムはまだOS Xに移植されていないため、anyパッケージシステムには表示されません。それにもかかわらず、これらのシステムはOS Xに同梱されるものを大幅に拡張し、Linuxからの移行を容易にします。

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

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

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

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

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

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

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

    タイピングは増えますが、新しいGCCから32ビットのビルドを取得できます。

  • ダイナミックリンケージは大きく異なります。

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

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

    最初に頭をひねるダイナミックリンケージのもう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は、Linuxとは異なる方法でCPU互換性の問題を処理します。

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

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

    Xcodeを使用してユニバーサルバイナリを構築するのは簡単ですが、コマンドラインツールを使用すると少し面倒です。これにより、Autoconfベースのビルドシステムでユニバーサルインテルのみのビルドが可能になります。

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

    PowerPCサポートが必要な場合は、-Arch ppc -Arch ppc64をCFLAGSおよびLDFLAGSに追加します。

    依存関係の追跡を無効にしないと、最初のプラットフォーム用に新しく構築された.oファイルが存在することで、2番目のプラットフォーム用にビルドする必要がないことをmake(1)に納得させるため、1つのプラットフォーム用にのみビルドされます。プラットフォームも。上記の例では、すべてを2回ビルドする必要があります。それでもPowerPCサポートが必要な場合は、完全にユニバーサルなバイナリの場合は4回。

    （詳しくは Apple Technical Note TN2137 をご覧ください。）

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

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

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

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

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

53
Warren Young

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

30
gabe.

FinkとMacPortsはOS Xでunixパッケージを取得する従来の方法ですが、brewと呼ばれる新しいツールをチェックすることをお勧めします。使用する。基本的にはtarballをダウンロードして/ usr/localにインストールするだけですが、プロセス全体を非常にうまく自動化します。

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

9
Sandy

巨大な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}"
4
taco

ネットワークスタックを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はありませんが、pollとkqueueがあります
3
Steve-o

以下は、選択した開発記事の良い情報源であるCocoa Literature Listです。

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

（これは、ある日Mac OS X固有の機能を利用したい場合に特に役立ちます。）

3
frank

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

1
andrewrk