[FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

Clément Bœsch u at pkh.me
Wed Jun 18 17:32:17 CEST 2014

On Wed, Jun 18, 2014 at 01:54:52PM +0000, Carl Eugen Hoyos wrote:
> Clément Bœsch <u <at> pkh.me> writes:
> > > > It's not needlessly since it fixes builds when libx264 is 
> > > > built against external libs to the least, without a hack 
> > > > of trying to guess what library could be needed. It 
> > > > simplifies the creation of static builds.
> > > 
> > > This sounds as if these were two different issues, 
> > > do I misunderstand?
> > > 
> > 
> > You don't misunderstand, I was enumerating a bunch of 
> > problems with the current hack.
> But the first issue (external libs) only exists 
> together with the second (static build), so there 
> is only one issue or am I wrong?

Sorry I'm not following you. You have multiple common scenarios. A typical
one is x264 being installed in a custom place, and where only the
libx264.a is available:

[~/src/x264]☭ ./configure --prefix=/tmp/myx264 --enable-static
[~/src/x264]☭ make -j5
[~/src/x264]☭ make install
[~/src/x264]☭ PKG_CONFIG_PATH=/tmp/myx264/lib/pkgconfig pkg-config --libs x264
-L/tmp/myx264/lib -lx264 -lpthread -lm -ldl 

I'm not even talking about having a FFmpeg full static build, just a
common install in a different place. Trying to guess if -lpthread -lm -ldl
will be necessary or not should *NOT* be up to the user.

We are probably lucky here since FFmpeg likely has those flags already, or
our toolchains are smart enough. I'm also not sure about what happens if
opencl is linked against libx264 but only a .a/.so of opencl is available.

Anyway, that's the kind of configuration where you don't have to care
about when you're using pkg-config because it deals with these issues for

So anyway: ffmpeg full static build, and external library static only are
two similar issues -yet different-; you can consider it to be one if you
want to, it doesn't really matter.

> > > > And also it simplifies specifying a custom x264 build.
> > > 
> > > It definitely doesn't simplify things, I honestly wonder 
> > > if everybody on this list knows how to use the future 
> > > variant, while I consider the current solution very 
> > > user-friendly.
> > 
> > Very user friendly? To specify compiler and linker flags 
> > manually?
> Yes.
> Compared of course to a variable that nobody (except 
> you) knows of and that no user will ever find.

What? man pkg-config.

pkg-config is more than common nowadays. We have about 20 libraries in
configure relying on this. And a lot of the remaining library lookup hacks
could probably benefit from it.

Of course, we may need to update our documentation. I don't mind
mentioning pkg-config in hundred places if that helps.

> (I am still hoping that Timothy proves me wrong.)
> > It says to install pkg-config?
> This unfortunately isn't the point.
> The point is that you still have to tell your 
> configure line where to search, and that this 
> is much simpler with the current implementation.

What's so much simpler? You have to know about the FFmpeg configure
options, you have to specify the install path twice (for compilation and
for linking), and you will probably miss a lot of flags depending on your

The options in FFmpeg's configure are FFmpeg specific. The PKG_CONFIG_PATH
environment variable is used in every project that relies on it. Most
people out there are more comfortable with pkg-config that the hacks in
our configure...

> And configure --help tells you about it.

We can document PKG_CONFIG_PATH in that configure help if that makes you
more comfortable.

Autotools do this in the --help, under the "Some influential environment
variables". That's basically how they control the paths of the libraries.
It's by way at an even above level since the scope of the path is not
shared between libraries.

Here is an example:

[~/src/vlc]☭ ./configure --help|grep -c pkg-config

> > Well, every time I wanted a custom build with special 
> > paths or options, I was always ended up reading or 
> > hacking the configure with echo to figure out what 
> > was going on.
> Sorry, I really don't understand that.
> In which situation was this ever necessary?

I didn't understand why my PKG_CONFIG_PATH was honored for some libraries
and not for others. I was actually convinced it was using pkg-config for
libx264 for some reason, and then I tried to figure out how to control the
paths. Trying to override the compiler and linker flags look pretty

> > > My other concern is more personal: I hate to install, 
> > > and particularly if it is not necessary.
> > > I would expect that this would also hit a few users, 
> > > possibly less than the pkg-config issue.
> > 
> > pkg-config is a 100kB standalone portable C program
> I meant I hate to install a custom x264 build.

Well there are a lot of reasons for doing this. A common one is having a
10-bit version. And generally that conflicts with a system installed one
so you put it in a random place. Not sure what's your point.

> Carl Eugen

Anyway, I feel like I've repeated myself too much already, I won't try to
convince you anymore. I guess I'll call for a vote or just let Michael
make a decision about that if there is no progress in the next days. I've
spent way too much time on this.

Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140618/9d0f53dc/attachment.asc>

More information about the ffmpeg-devel mailing list