2012-12-09 20 views
6

Linux Mint 14 NadiaにMatlabをインストールしました(uname -aが表示されます:Linux Ideapad-Z570 3.5.0-17-ジェネリック#28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux )、コマンドラインから呼び出すときには、 "/lib64/libc.so not found"と表示されます。/lib/i386-linux-gnu/libc.so.6、/lib/x86_64-linux-gnu/libc.so.6と/usr/lib/x86_64-linux-gnu/libc.soの違いは何ですか? ?

私がように/ lib64にリンクすることによって、MathWorks社のヘルプを追っ:

ln -s /lib/x86_64-linux-gnu/libc.so.6 . 

問題を解決すること。私はこのライブラリを見つけなければ今

は、私が手:私はこのコンピュータにgccでコンパイルされ、私は完全な64ビットのコンパイルがしたい

locate "libc.so" 
/lib/i386-linux-gnu/libc.so.6 
/lib/x86_64-linux-gnu/libc.so.6 
/usr/lib/x86_64-linux-gnu/libc.so 

。これらの異なるlibc.soライブラリをすべて持つことは、どういう意味ですか? gnuコンパイラはどちらを使用しますか?私は64ビット用にコンパイルするためにgccと何か異なることをする必要がありますか?

私は新しいi7コアのためにできるだけ多くを最適化したいと思います!使用するかを調べるに

+0

user1889975、こんにちは。 3つの 'libc.so'がすべて異なっていると確信していますか?シンボリックリンクを見つけるには 'ls -l'を実行してください。また、混在した32/64ビットシステム( '/ lib64'から'/lib/tr-ip-le/'に)の32/64bit libsへのデフォルトパスに最近変更があり、このページで追加情報http: //wiki.debian.org/Multiarch/TheCaseForMultiarch – osgx

+0

私はチェックしましたが、シンボリックリンクではありません。ご提案ありがとうございました – Alejandro

答えて

10

/lib/i386-linux-gnu/libc.so.6

これをisはライブラリの32ビットバージョンです。

/lib/x86_64-linux-gnu/libc.so.6

これは、ライブラリの64ビットバージョンです。

はどちら

例えばlibc-2.15.so

、通常は通常、glibcのリリース番号に従って命名される実際のライブラリファイルへのシンボリックリンクです/usr/lib/x86_64-linux-gnu/libc.so

これはライブラリではなく、上記のシンボリックリンクを参照するリンカスクリプトファイルです。

なぜ私たちは、これらすべてが必要なのです:コンパイラー・ドライバーは、常にリンカに-lcオプションを渡しますので

まず、関係なく、インストールlibcのバージョンの、リンカは常に、libc.soを検索します。 libcという名前は同じままであり、ライブラリの最新バージョンを示します。

シンボリックリンクはlibc.so.6は、ライブラリのSONAME、ライブラリのABIバージョンに、多かれ少なかれ対応にちなんで命名されています。実際にlibc.soにリンクされている実行可能ファイルには、libc.so.6にランタイム依存関係が含まれています。

我々はいつかを想像する場合は肉眼的にABI互換性のないlibcのがリリースされ、それは例えば、SONAMEがlibc.so.7名前を付けることができだと、このバージョンのcoukldが古いlibc.so.6バージョンと共存、したがって、どちらか一方にリンクされ実行可能ファイルが同じで共存することができますシステム

最後に、libc-2.15.soという名前はlibcリリースを指します。新しいlibcパッケージをインストールすると、名前はlibc-2.16.soに変更されます。以前のリリースとバイナリ互換性がある場合は、libc.so.6リンクの名前がそのままになり、既存の実行可能ファイルは引き続き動作します。

+0

ありがとうございました。これはなぜ私が多くを理解するのを助けた。 – Alejandro

+0

リンカスクリプトに '.so'という名前を付けているのはなぜですか?それは混乱している。 –

2

、最初ld(リンカ)はライブラリを見つけるために使用する順序を見つける必要があり、そのよう:

:私にとって

ld --verbose | grep SEARCH 

それは私にこの出力を与えました

SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64"); SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib"); 

これは私のコンピュータ上で、ldは順番に、これらのディレクトリに見えることを意味します

  1. は/ usr/x86_64版-unknown-のlinux-gnuの/ lib64に
  2. のlib/
  3. は/ usr/x86_64の-未知のlinux-gnuの
  4. は/ usr/libに
  5. /usr/local/libディレクトリ

のlibcはしていたので、あれば/ usr/x86_64-unknown-linux-gnu/lib64であり、libcも/ usr/libにあり、最初にリストされているため/ usr/x86_64-unknown-linux-gnu/lib64バージョンが使用されます。

+0

非常に興味深くて有用です。ありがとうございました。私の場合は、 "/ lib/x86_64-linux-gnu"という文字列が最初に表示されるので、64ビットコードをコンパイルするのがよいでしょう。 これを完全に理解したいと思います。なぜ私のLinuxディストリビューションはこのライブラリをいくつかの異なる場所にインストールしましたか? – Alejandro

+0

@Alejandro、問題ありません!それが解決すれば、そのようにマークできますか? – MiJyn

+0

申し訳ありませんが、私はまだ多くの場所がなぜ知りたいですか?これらのファイルは何度も繰り返しコピーされていますか?私が推測する理由があるかもしれません。 私はこれらの答えを得ると解決したものとしてマークします。ありがとうございました! – Alejandro

0

あなたが作成したシンボリックリンクは、GCCでは何の効果もありません。 32ビット版は、GCCフラグ-m32を使用してコンパイルする場合にのみ使用されます。あなたは、具体的にそれを教えてくれない限り、GCCは、32ビットのバイナリを生成しようとはしません(このフラグを使用することによって。)

+1

gccがデフォルトで64ビットコードをコンパイルするかどうかについては、非常に明確です。 – Alejandro

関連する問題