PLEASE PLEASE avoid using sid/jessie repos at the same time, I SEVERELY broke the apt-get package manager by doing this and ended up not being able to recover. I ended up having to reinstall the entire Debian OS, lmao.

Recently adding the Debian sid repos to my sources.list, I found that upgrading a certain few packages related to libimobiledevice-dev (in order to transfer photos from my iPhone 6S to my computer) caused other libraries to be needed to be upated. Of course, out of all the possible libraries, one of the libraries that was updated broke FFmpeg.


I was led on this frustrating adventure by my desire to move pictures from my iPhone to my computer. I could have gone the simple way and just used iTunes or something on a Windows computer, but you know what? It just happens that I have a backup folder already with all my photos on my Debian computer.

Simply the most magical thing about Debian is how I was able to USB transfer all the earlier photos from my phone to my computer without trouble, but I’d get Unhandled lockdown errors whenever I mount my iPhone this time around.

Forgetting to read the portion about using the jessie-backports workaround, I rashly went to use the sid repos instead…

The Problem

A few packages later (using apt-get dist-upgrade I think?), I was rather surprised to find that OBS had stopped working. Whenever I’d enter obs into terminal, it would spit out something like the following:

obs: symbol lookup error: /usr/lib/x86_64-linux-gnu/
undefined symbol: FT_Outline_EmboldenXY

No problem. Can’t be part of the package update, right… (it was)? I do a quick google search and discovered the following:

  1. This was related to FFmpeg, not actually OBS
  2. This works:
cd /usr/lib/x86_64-linux-gnu

The latter point was in particular, the most baffling thing about the whole issue. I couldn’t comprehend how being in a specific library directory ended up allowing FFmpeg to work. I did not want to have to switch into this directory every time I needed to use FFmpeg, so I decided to attempted to fix the issue by compiling a new version of FFmpeg…

Fixing it

I decided to recompile FFmpeg to try my luck and see if it is simply a minor library error (?? not even sure what I was thinking at the time).

Now I tried a wide variety of different compile options, including this nifty script which I used previously to install OBS and FFmpeg.

Surprise, surprise. It didn’t work.

Knowing that it was a problem with libass, I was damned to find that even the FFmpeg build in the sid repos did not even work with the libass version packaged for that jessie or testing.

Basically in order to fix the problem, I cannot use dynamic links to the new version of libass, but I needed to retain a static link to the previous one with the FFmpeg binary.

I actually had modified the previous script exactly for this purpose, but in being new to this whole static thing, I mixed up --enable-shared and --enable-static flags multiple times. It turns out however, that the two don’t really have anything in particular that relates them. Unbeknownst to me, I kept trying different combinations of fruitlessly changing the flags only to get linking errors with x264 and libass.

In short, shared vs. static:

  1. Shared flag - writes .so files to the library path for other binaries that use dynamic libraries to load the library. Newer versions replace this .so file with the newer version, thus updating for all binaries using this library.
  2. Static flag - does not use .so file, but rather an .a file that is always the same. Updates do not affect static libraries, as the name “static” implies.

In the end, I went with using this script, but with a few minor modifications:

diff --git a/ b/
index f94fdbe..cfc8a61 100755
--- a/
+++ b/
@@ -160,7 +160,7 @@ make install
 echo "*** Building libvpx ***"
 cd $BUILD_DIR/libvpx*
 [ $rebuild -eq 1 -a -f Makefile ] && make distclean || true
-[ ! -f config.status ] && PATH="$BIN_DIR:$PATH" ./configure --prefix=$TARGET_DIR --disable-examples --disable-unit-tests --enable-pic
+[ ! -f config.status ] && PATH="$BIN_DIR:$PATH" ./configure --prefix=$TARGET_DIR --disable-examples --disable-unit-tests --enable-shared --enable-pic
 PATH="$BIN_DIR:$PATH" make -j $jval
 make install
@@ -196,6 +196,7 @@ PKG_CONFIG_PATH="$TARGET_DIR/lib/pkgconfig" ./configure \
   --enable-libvpx \
   --enable-libx264 \
   --enable-libx265 \
+  --enable-nvenc \
 make install

I made a minor fix to VPX not being able to detected, although I am not completely sure how that is supposed to work.

(Quick note: NVENC capability dynamically loads files from the library path from the nVidia SDK, no compilation needed. I did not add a script to download the files because a) the toolkit requires signing in and b) I already have the files)


I was eventually able to install OBS using the ffmpeg-static build script to build FFmpeg. Everything worked out in the end (except for one minor caveat that ffplay is never compiled, I will need to figure that out). If OBS is missing an FFmpeg compile dependency, then use --enable-shared to allow OBS to use them as well. Otherwise, errors such as missing libswrescale can be fixed using the sid packages.