[FFmpeg-devel] Fix libx264

Felipe Contreras felipe.contreras
Wed Feb 24 01:16:07 CET 2010


2010/2/23 M?ns Rullg?rd <mans at mansr.com>:
> Nicolas George <nicolas.george at normalesup.org> writes:
>> pkg-config is an attempt to solve the problem caused by these compilers that
>> requires non-standard flags. It is not perfect, it has limitations, but at
>> the very least it works better than nothing in the default case.
>
> I would argue pkg-config at best changes nothing, and more commonly
> makes matters worse.

This thread was started because linking to a statically linked x264
doesn't work (unless you manually specify --enable-*threads), the
solution is very simple: add -lpthread (or similar) (even if FFmpeg is
not using threads).

So there you go; it does change something.

Moreover, say a mingw32 build environment requires -lpthreadGC2
-lws2_32, in that case not even --enable-w32threads will fix the
linking problem because at best FFmpeg's configure script will only
check for -lpthreadGC2.

Using pkg-config would solve these problems, and if future
dependencies are added; FFmpeg's configure script wouldn't need to be
updated.

You keep saying things like "more commonly makes matters worse",
however, not a single real example has been provided where things
would break. So the choices are:

a) use pkg-config and fix *real* current problems
b) don't use pkg-config because of fictional problems

Note that the proposal is not to add pkg-config everywhere, only in
the case of x264. Therefore the "pkg-config generally makes things
worse" argument is not valid, we are talking about specifics here.

>> And of course, one of its limitations is that it is bound to one
>> compiler. I do not know how you would expect it to magically guess
>> the options for others compilers.
>>
>> If you have suggestions on how something better than pkg-config can be
>> implemented, I would really like to hear them.
>
> If you insist on that general approach, which is of course flawed,
> there are still things that could be done better. ?Instead of storing
> specific compiler flags directly, the .pc files could list more
> abstract requirements, e.g. "threads", which could then be mapped to
> whatever flags each compiler requires. ?In fact, this would be
> possible to do with no change to pkg-config itself by installing
> "threads.pc" files for each compiler, and letting the user choose the
> proper one with environment variables.

That is a good idea, and should definitely be pushed forward since
it's a cleaner solution. But that doesn't mean other uncleaner
solutions wouldn't work just fine.

Note: I'm not trying to get you to answer this (given your previous
responses), but I do hope other people are interested.

Cheers.

-- 
Felipe Contreras



More information about the ffmpeg-devel mailing list