回答:
別のオプションはlipo
です。その出力は簡潔で、のものより読みやすくなっていotool
ます。
例:
% lipo -info /usr/lib/libiodbc.a
Architectures in the fat file: /usr/lib/libiodbc.a are: x86_64 i386 ppc
% lipo -info libnonfatarchive.a
input file libnonfatarchive.a is not a fat file
Non-fat file: libnonfatarchive.a is architecture: i386
%
file
おそらく教えてくれます。otool
確かにできるはずです。しかし、私はfile
最初に試します、例えば
logan:/Users/logan% file d2
d2: Mach-O executable ppc
アーカイブの例:
logan:/Users/logan% file /usr/lib/libMallocDebug.a
/usr/lib/libMallocDebug.a: Mach-O universal binary with 2 architectures
/usr/lib/libMallocDebug.a (for architecture i386): current ar archive random library
/usr/lib/libMallocDebug.a (for architecture ppc): current ar archive
file
しばしば失敗します。
前述のように、file
常に機能するとは限りません。otool -hv -arch all
おそらく、動作が保証されている最も近いものです。ライブラリ内のすべてのオブジェクトファイルのアーキテクチャ情報を提供します。
例:
%otool -hv /sw/lib/libfftw3.a アーカイブ:/sw/lib/libfftw3.a /sw/lib/libfftw3.a(align.o): マッハヘッダー magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 3 336 SUBSECTIONS_VIA_SYMBOLS /sw/lib/libfftw3.a(alloc.o): マッハヘッダー magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 3 416 SUBSECTIONS_VIA_SYMBOLS ...
別の方法として、私はうまくいくことobjdump
ができることがわかりました。例として、私の環境でvxWorksを使用してライブラリアーカイブを構築し、それらを他のプロジェクトにリンクする必要があります。アーカイブが正しいアーキテクチャであるかどうかをテストするには、次のようにします(bash構文)。
if [ "$(objdumpsparc -a ${ARCHIVE_FILE} 2>&1 | ggrep -cvP 'elf32-sparc-vxworks')" -ne "0" ]; then
echo "Cannot build with ${ARCHIVE_FILE}, it contains one or more non-sparc components"
fi;
この例は正確ではありません。elf32-sparc-vxworksを示さない一部の行が表示されるためですが、これを適応させるのは簡単です。
これの優れた利点の1つは、、objdump
または同様の名前のバリアントがほとんどの* nixオペレーティングシステムにインストールされているのに対し、他の応答で提案されているツールはインストールされていないことです。
編集これは、OPがOSXで要求していたことを思いつきました。謝罪いたします。
objdump
するには、MacPorts経由でGNU Binutilsをインストールできます。使用可能なすべてのアーキテクチャを確認するには、を実行しport search binutils
ます。ネイティブ開発用のツールには、競合を回避するために接頭辞が付けられます(例:のgobjdump
代わりobjdump
)。便宜上、エイリアスを作成することをお勧めします。