Linux shared build, maybe use $ORIGIN/../lib as the rpath is a better solution

[SuperdukeGates]

I downloaded the ffmpeg-master-latest-linuxarm64-gpl-shared.tar.xz and found that I can't run the ffmpeg from other directory.

$ pwd
/home/btbn
$ ~/ffmpeg/bin/ffmpeg
/home/btbn/ffmpeg/bin/ffmpeg: error while loading shared libraries: libavdevice.so.62: cannot open shared object file: No such file or directory

I use ldd to show the shared libraries of ffmpeg, I found that they are related path.

$ ldd ~/ffmpeg/bin/ffmpeg
        linux-vdso.so.1 (0x0000007f97f70000)
        libavdevice.so.62 => not found
        libavfilter.so.11 => not found
        libavformat.so.62 => not found
        libavcodec.so.62 => not found
        libswresample.so.6 => not found
        libswscale.so.9 => not found
        libavutil.so.60 => not found
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f97dec000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f97dbd000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f97c4c000)
        /lib/ld-linux-aarch64.so.1 (0x0000007f97f42000)

I can use LD_LIBRARY_PATH=/home/btbn/ffmpeg/lib to run ffmpeg from other directory.

But I found we can use $ORIGIN rpath token to solve this problem when linking ffmpeg. Although I never tried.

$ man ld.so
   Rpath token expansion
       The dynamic linker understands certain token strings in an rpath specification (DT_RPATH or DT_RUNPATH).  Those strings are substituted as follows:

       $ORIGIN (or equivalently ${ORIGIN})
              This expands to the directory containing the program or shared object.  Thus, an application located in somedir/app could be compiled with

                  gcc -Wl,-rpath,'$ORIGIN/../lib'

              so that it finds an associated shared object in somedir/lib no matter where somedir is located in the directory hierarchy.  This facilitates the  creation  of
              "turn-key"  applications  that  do  not need to be installed into special directories, but can instead be unpacked into any directory and still find their own
              shared objects.

[BtbN]

Not sure if the build system can be convinced to do that. And what the security implications of it would be.
The shared builds are generally meant for people who need the libraries, not the CLI tools.
If you want to run them, I'd recommend the non-shared builds.

[MagicalDrizzle]

I still think it's using shared builds has the advantage of saving space.