回答:
別のオプションは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)。便宜上、エイリアスを作成することをお勧めします。