Building in libmp3lame

Questions that occur when trying to compile FFmpeg.
Post Reply
Posts: 6
Joined: Sun Mar 23, 2014 6:49 pm

Building in libmp3lame

Post by darkmoon »

I'm building ffmpeg under Linux. Yes, I know, this is a windows site, but still someone might have some insight into this problem.

The customized ffmpeg build system demands that external libraries be recognized by pkg-config before it will build them into ffmpeg. pkg-config looks for a small companion file. [libname].pc, that has details about dependencies and such for each library. libmp3lame doesn't generate one. Is this a problem when building for Windows with MSYS or Cygwin -mno-cygwin as well? If it is, how do you work around it? Zeranoe, can you help with this one? Thank you,


Posts: 94
Joined: Thu Aug 22, 2013 5:14 pm

Re: Building in libmp3lame

Post by Reino »

I'm sure you already read Carl's answer: "lame still works without pkgconfig."
FFmpeg's 'configure' doesn't demand a pkg-config file for libmp3lame:

Code: Select all

enabled libmp3lame       && require "libmp3lame >= 3.98.3" lame/lame.h lame_set_VBR_quality -lmp3lame $libm_extralibs

Posts: 84
Joined: Wed Jan 23, 2013 4:10 pm

Re: Building in libmp3lame

Post by qyot27 »

Okay, let's try to start out at the beginning.

You don't need to rename any of the .pc files installed by the individual projects. FFmpeg uses the names as they were installed (not that I think it matters, as I'm pretty sure pkg-config only cares about the Name: field in the *.pc file itself). They should even be picked up by the system defaults for PKG_CONFIG_PATH. The only thing absolutely necessary if you're building these as static is to use --pkg-config-flags=-static when configuring FFmpeg so that it tells pkg-config that the Libs.private field is to be honored wherever it occurs in the .pc files being used.

libmp3lame doesn't use pkg-config. At all. That's why no *.pc file gets generated. LAME's source code doesn't even ship with the * template for one.

Yes, some of the dependencies (mp3lame and Xvid, IIRC) require using --extra-libs="-lpthread -lm" to add those to the linker list and allow those encoders to be properly enabled. This is sometimes true of both Linux and Windows - on native Linux builds, I do need to use that. On Windows (rather, on Linux cross-compiling for Windows), it's really only an issue for 64-bit builds, and I think only for Xvid.

I don't bother trying to build fully-static Linux binaries of FFmpeg, and just rely on the repo -dev packages for many of its dependencies (which means, anything from the repo = shared, anything I personally build = static), and the necessary compilation instructions for each piece will differ amongst operating systems and host/target CPUs. With that said, you might find the cross-compilation guide I maintain informative: ... s.txt#L332

In most cases, those instructions will be mostly the same for native Linux builds too, just remove the cross-compilation-related parts (--host=, --build=, --prefix=, checkinstall using package names with -mingw-<arch> suffixes; the particulars for the CMake-using pieces are similar). Also, on Linux you're probably not going to be interested in doing multilib builds, so you don't have to build these things twice.

I'd suggest switching to mbedTLS (formerly known as PolarSSL, which, way back when RTMPDump was still a thing, was usually the best way to build that particular piece) instead of GnuTLS. It's far easier/faster to build and it means not having to use --enable-gnutls or --enable-gmp and deal with the web of dependencies there.

Code: Select all

git clone git:// && \
cd mbedtls && \
cmake -G "Ninja" -DCMAKE_C_FLAGS="-march=native" && \
ninja && \
    sudo checkinstall --pkgname=mbedtls --pkgversion="$(grep \
    MBEDTLS_VERSION_STRING include/mbedtls/version.h | head -1 | \
    cut -f2 -d "\"")-$(date --rfc-3339=date | sed 's/-//g')-git" --backup=no \
    --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no \
    --default ninja install
The above is the Linux-specific way to build it. The MinGW-w64 instructions in the aforementioned guide are here, so you can compare and contrast the different instructions needed for Linux vs. Windows cross-compiles.

Post Reply