Question

我正在从源代码编译FFmpeg。

./configure --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-x11grab --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264
make
make install

ldd /usr/local/bin/ffmpeg给了我这个

linux-gate.so.1 =>  (0xb7717000)
libavdevice.so.53 => not found
libavfilter.so.2 => not found
libavformat.so.54 => not found
libavcodec.so.54 => not found
libpostproc.so.52 => not found
libswresample.so.0 => not found
libswscale.so.2 => not found
libavutil.so.51 => not found
libm.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libm.so.6 (0xb76e3000)
libpthread.so.0 => /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0 (0xb76ca000)
libc.so.6 => /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6 (0xb7569000)
/lib/ld-linux.so.2 (0xb7718000)

将$LD_LIBRARY_PATH设置为/usr/local/lib更正了“未找到”错误，但由于提到here的原因，我不想永久设置$LD_LIBRARY_PATH。

我推荐使用相同的命令，这次将$LD_RUN_PATH设置为/usr/local/lib 编译时，make似乎忽略了$LD_RUN_PATH。

有没有办法在不对Makefile进行大量更改的情况下使用$LD_RUN_PATH？

Answer 1

您是否有理由在共享模式下编译二进制文件（比如想要构建软件来链接它们）？如果静态'ffmpeg'二进制文件对您来说同样适用，请在不使用--enable-shared选项的情况下进行配置以消除这些依赖关系。

否则，您需要让系统知道共享库所在的位置，方法是在环境中设置LD_LIBRARY_PATH，在前面执行'ffmpeg'和LD_LIBRARY_PATH（例如，“LD_LIBRARY_PATH = / usr / local / lib / usr / local / bin / ffmpeg“），或者使用正确的位置更新系统的库路径。

还有一个解决方案位于您在帖子中链接的页面的最底部：“LDFLAGS =' - L / my / strange / path / lib -Wl，-rpath / my / strange / path / lib “”。对于FFmpeg以及您的情况，请在配置时传递此额外参数：

--extra-ldflags="-L/usr/local/lib -Wl,-rpath /usr/local/lib"

生成的'ffmpeg'二进制文件将知道在哪里可以找到共享库。

这个的许多解决方案。

Answer 2

最有可能忽略LD_RUN_PATH因为包的./configure已经在链接器的cmdline中放了一些-Wl，-rpath选项（坦白说我不知道自己。我在这里看到相同的行为，但我正在交叉编译从486到mips32）。
尝试像这样运行configure： ./configure LDFLAGS =“ - L / your / lib -Wl，-rpath-link = / your / lib”CPPFLAGS =“ - I / your / include”--prefix = / tgt ...

如果/您的目录与/ tgt

Answer 3

对于偶然发现这一点的其他人来说，$LD_RUN_PATH无效的原因可能是this bug与黄金链接器有关。

（解决方法是使用Mike的答案中描述的rpath）

make：$ LD_RUN_PATH被忽略

3 个答案: