タグ付けされた質問 「shared-library」

32ビットLinuxシステムでは、これを呼び出します $ /lib/libc.so.6 そして、64ビットシステムではこれ $ /lib/x86_64-linux-gnu/libc.so.6 シェルでは、次のような出力を提供します。 GNU C Library stable release version 2.10.1, by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. …

55 linux  executable  glibc  version  shared-library 

システムが使用しているユーザーランドCライブラリを確認するにはどうすればよいですか？この情報を必要とする考えられる理由は次のとおりです。 ダウンロードを検討している巨大なソースパッケージがあり、適切なチェックを行い、最小ライブラリバージョンをリストしますが、動作するかどうかを最初にチェックすることで、面倒な作業を省くことができます。 システムのパッケージ管理システムの外部で試してインストールしたいサードパーティのバイナリとABIの互換性が心配です。 私のシステムのライブラリの最小バージョンの必要性について言及しているドキュメントのソースパッケージがありますが、ビルドプロセスはチェックを実行しません。 特定のシステムをターゲットとするクロスコンパイラを構築していますが、前方互換性の問題を危険にさらしたくないです。

43 c  version  shared-library 

printfを含むlibc.so.6ファイルに多くのシンボルが表示されると予想していました。nmツールを使用してそれらを見つけましたが、libc.so.6にはシンボルがないと書かれています。

31 linux  shared-library  symbol-table  nm 

strace出力、実行可能ファイルが呼び出すことをライブラリへのパスが呼び出しですopen()。これは、動的にリンクされる実行可能ファイルで使用されるシステムコールですか？どうdlopen()？open()プログラムの実行に役割を果たすとは思いませんでした。

23 dynamic-linking  shared-library  strace  dynamic-loading 

リンクされたライブラリ（libz.so.1.2.7）を必要とする「alpha」という名前のバイナリ実行可能ファイルがあります。 /home/username/myproduct/lib/libz.so.1.2.7 次のコマンドを実行してバイナリ実行可能ファイルを生成する前に、同じものをターミナルインスタンスにエクスポートします。 export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH さて、同じライブラリを必要とするがバージョンが異なる別のアプリケーション「bravo」、つまりで使用可能な（libz.so.1.2.8）を生成すると /lib/x86_64-linux-gnu/libz.so.1.2.8、システムは次のエラーをスローします。 version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2) の設定を解除するとLD_LIBRARY_PATH、「bravo」が正常に起動します。上記の動作は、リンクされたライブラリの検索中にLD_LIBRARY_PATH定義されたディレクトリパスよりも優先される/etc/ld.so.confため、上記のエラーが発生することを理解しています。ライブラリの最初のインスタンスが異なるバージョンである場合、UNIX / LINUXの開発者が、階層に従って他のディレクトリ内のリンクされたライブラリを検索するようにOSを設計しなかった理由に興味があります。 簡単に言えば、UNIX / LINUXシステムは、必要なライブラリが見つかるまで一連のディレクトリを走査します。しかし、バージョンに関係なくライブラリの最初のインスタンスを受け入れるのではなく、予想されるバージョンが見つかるまで同じことをしないのはなぜですか？

17 libraries  dynamic-linking  shared-library  ld 

私の質問は、ffmpegを開始する際の問題から生じています。ffmpegをインストールしましたが、インストール済みと表示されます： whereis ffmpeg ffmpeg: /usr/bin/ffmpeg /usr/bin/X11/ffmpeg /usr/share/ffmpeg /usr/share/man/man1/ffmpeg.1.gz 後で、一部のプログラムはインストール自体に付属していないライブラリに依存していることがわかりました。そのため、lddコマンドで不足しているものをチェックしました。 # ldd /usr/bin/ffmpeg linux-vdso.so.1 => (0x00007fff71fe9000) libavfilter.so.0 => not found libpostproc.so.51 => not found libswscale.so.0 => not found libavdevice.so.52 => not found libavformat.so.52 => not found libavcodec.so.52 => not found libavutil.so.49 => not found libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5f20bdf000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 …

14 linux  libraries  ffmpeg  etc  shared-library 

（ダイナミックリンカー/ローダー）/bin/bashを含むの共有オブジェクトの依存関係を考慮します/lib64/ld-linux-x86-64.so.2。 ldd /bin/bash linux-vdso.so.1 (0x00007fffd0887000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f57a04e3000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57a04de000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57a031d000) /lib64/ld-linux-x86-64.so.2 (0x00007f57a0652000) 検査/lib64/ld-linux-x86-64.so.2すると、それが次へのシンボリックリンクであることがわかり/lib/x86_64-linux-gnu/ld-2.28.soます。 ls -la /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 32 May 1 19:24 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so さらに、それ自体へのfileレポート/lib/x86_64-linux-gnu/ld-2.28.soは動的にリンクされます。 file -L /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, …

12 linux  dynamic-linking  shared-library  file-command 

RedHat / CentOSに関連する質問。私はパッケージとライブラリ、そしてそれらを固定バージョンに固定する方法について少し混乱しています。 最近のlibxcbバージョンには、私のCプログラムに影響するX11ロールオーバーのバグがあります。libxcb-1.5-1にはそのバグはありません。 だから私はしました： # yum remove libxcb-devel # rpm -Uvh --oldpackage libxcb-1.5-1.el6.i686.rpm そして今、バグはなくなり、私のソフトウェアは正常に動作します。 数週間早送りして、バグが戻ってきました。 # yum info libxcb-devel Loaded plugins: refresh-packagekit, security Available Packages Name : libxcb-devel Arch : i686 Version : 1.9.1 Release : 2.el6 Size : 1.0 M Repo : sl-security しかし、それはインストールされているバージョンですか、それともリポジトリから入手できるバージョンですか？現在インストールされているlibxcbのバージョンを確認するにはどうすればよいですか？ $ ll /usr/lib/libxcb.so* lrwxrwxrwx …

11 rhel  yum  shared-library 

多くの場合、特定のプログラムがライブラリバージョンxyとxzに依存するプログラムがありますが、私が知る限り、xyとxzの両方をインストールできるパッケージマネージャーはありません。 qt4とqt5は同時にインストールできます）が、（おそらく）マイナーバージョンではありません。 どうしてこれなの？のように、それを妨げる制限要因は何ですか？この一見便利な機能を許可しないことには、十分な理由があるはずだと思います。たとえば、共有オブジェクトをロードするときにロードするバージョンを示すフィールドがないため、Linuxがロードするものを決定する方法を知る方法はありませんか？それとも理由は本当にないのですか？とにかく、すべてのマイナーバージョンは互換性があると思われますか？

10 package-management  dynamic-linking  version  shared-library 

ソフトウェアを手動でインストールしているように見えるたびに、共有ライブラリエラーが発生します。実行するecho $LD_LIBRARY_PATHと、何も表示されません。私はファイルに追加しようとし/usr/local/libましたが、.conf実行され/etc/ld.so.conf.dないようです。 これも機能しません（引用符など）： LD_LIBRARY_PATH="/usr/local/lib" export LD_LIBRARY_PATH sudo ldconfig -v 値は一時的に設定されますが、ターミナルウィンドウを終了した場合、値は保持されません。再起動しても何も起こりません。

9 sudo  environment-variables  shared-library 

Linux / ARMの共有ライブラリ内の関数の呼び出しを追跡できるツールを探しています。基本的に、コマンドラインを指定し、このツールで呼び出されたライブラリ関数と渡された引数のレコードを生成できるようにしたいと考えています。このために、何らかの形の関数フッキングを使用できると思います。 私が知っているはltrace、必要な機能を正確に提供します。しかし、ltraceそれは私にとってはうまくいきません： より複雑なプログラムをトレースすると、segfaultになることがよくあります。 非常に遅いです。 より堅牢な代替手段を探しています。スピードはいいですが、私の主な関心事ではありません。主に、任意の（非回避的）プログラムを分析できるライブラリー呼び出しをトレースする手段が必要です。 SysdigもARMでは機能せず、dtraceの移植はまだNetBSDでのみベータ版で機能しています。 誰かがそのようなツールを使用可能な状態で知っていますか？

8 linux  arm  debugging  shared-library  trace 

/proc/pid/maps同じライブラリのいくつかのレコードが含まれているのはなぜですか？次に例を示します。 7fae7db9f000-7fae7dc8f000 r-xp 00000000 08:05 536861 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20 7fae7dc8f000-7fae7de8f000 ---p 000f0000 08:05 536861 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20 7fae7de8f000-7fae7de97000 r--p 000f0000 08:05 536861 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20 7fae7de97000-7fae7de99000 rw-p 000f8000 08:05 536861 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.20 これは何を意味するのでしょうか ？

8 linux  process  memory  virtual-memory  shared-library