7

I'm compiling FFmpeg from source. 

./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 gave me this

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)

Setting $LD_LIBRARY_PATH to /usr/local/lib corrected the "not found" errors, but for the reasons mentioned here, I don't want to set $LD_LIBRARY_PATH permanantly.

I recomiled with the same commands, this time with $LD_RUN_PATH set to /usr/local/lib.
make seem to have ignored $LD_RUN_PATH when compiling.

Is there a way to use $LD_RUN_PATH without making extensive changes to the Makefile?

htoip
  • 437
  • 5
  • 19
  • Can you link successfully by hand (i.e. on the command line, without using make)? – Beta Mar 08 '12 at 18:49
  • I don't know. How can I test that? – htoip Mar 08 '12 at 19:02
  • Could you show us the part of the makefile that executes `ldd /usr/local/bin/ffmpeg`? – Beta Mar 08 '12 at 19:07
  • How did you configure FFmpeg (i.e., what options did you pass to the ./configure script)? How did you install FFmpeg after building; did you manually copy 'ffmpeg' over to /usr/local/lib? Or did you perform 'make install'? – Multimedia Mike Mar 08 '12 at 20:46
  • Check out http://linux.die.net/man/8/ld-linux for the variables `LD_DEBUG` and `LD_DEBUG_OUTPUT`. – 0xC0000022L Mar 08 '12 at 21:20

3 Answers3

7

Do you have a reason to be compiling the binary in shared mode (like wanting to build software to link against them)? If a static 'ffmpeg' binary will work just as well for you, configure without the --enable-shared option to eliminate these dependencies.

Otherwise, you will need to let your system know where the shared libraries live, either by setting LD_LIBRARY_PATH in the environment, prefixing executions of 'ffmpeg' with LD_LIBRARY_PATH (e.g., "LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/ffmpeg"), or update your system's library path with the right location.

There is one more solution that is at the very bottom of the page you linked in your post: "LDFLAGS='-L/my/strange/path/lib -Wl,-rpath /my/strange/path/lib'". For FFmpeg, and for your situation, pass this extra parameter at configure time:

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

And the resulting 'ffmpeg' binary will know where to find the shared libraries.

Many solutions to this one.

Multimedia Mike
  • 12,660
  • 5
  • 46
  • 62
  • I don't know if I need the shared option, but that what the instructions use. The `--extra-ldflags` worked perfectly. – htoip Mar 08 '12 at 23:23
3

  1. Most probably LD_RUN_PATH is ignored because package's ./configure has already put some -Wl,-rpath options in linker's cmdline (frankly I don't know myself. I see the same behaviour here but I'm cross compiling from 486 to mips32).

  2. try running configure like this: ./configure LDFLAGS="-L/your/lib -Wl,-rpath-link=/your/lib" CPPFLAGS="-I/your/include" --prefix=/tgt ...

    I recommend using -rpath-link instead of -rpath if /your directory is different from /tgt

xrgtn
  • 31
  • 1
2

For anyone else who stumbles across this, the reason $LD_RUN_PATH wasn't working may have been due to this bug with the gold linker.

(The workaround is to use rpath as described in Mike's answer)

Nick
  • 7,700
  • 2
  • 29
  • 37