[FFmpeg-devel] Fix libx264

Måns Rullgård mans
Tue Feb 23 20:25:32 CET 2010


Nicolas George <nicolas.george at normalesup.org> writes:

> Le quintidi 5 vent?se, an CCXVIII, M?ns Rullg?rd a ?crit?:
>> Yes, the compiler is part of the build environment.
>
> Well, .pc files are too. If you use a different compiler, you have to use
> different .pc files, that's all.

Where do you propose I obtain those?  The .pc files are installed when
the library is built/installed, and contain flags suitable for the
compiler it was built with.  The answer is no, as I suspect you might
suggest, to build the lib with the same compiler.  This is probably
not even possible, given that most pkg-config using libs work poorly
with non-gcc compilers.

>> POSIX standardises a few common compiler flags (-I, -L, etc.), and
>> pretty much all relevant compilers support these.
>> 
>> You are proposing to _intentionally_ break compatibility between
>> compilers where no issue would exist absent pkg-config.
>
> I am not proposing to break anything.
>
> There are pretty common compilers/build environments that requires
> non-standard flags to work, especially with threads but not only (sockets on
> Solaris anyone?). They do not respect the standard, that's too bad, but they
> exist and people use them, that's a fact.

Requiring -lsocket for those functions is not a violation of any
relevant standard.  Same for -lrt et al.

> 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.

> 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.

Even with a fix like this, pkg-config is still fundamentally broken
for reasons too numerous to list here.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list