[FFmpeg-devel] Fix libx264

[Nicolas George]

Le quintidi 5 vent?se, an CCXVIII, M?ns Rullg?rd a ?crit?:
> 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.

No need to build the whole library, there is a Makefile, it can build any
individual part you want it to build.

>						    This is probably
> not even possible, given that most pkg-config using libs work poorly
> with non-gcc compilers.

Let me rephrase: how do we know the build flags for a library that requires
non-standard build flags with a compiler that is not supported by that
library's build system?

You are begging the answer, are you not?

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

It is not a violation (because Sun paid big bucks to the Unix consortium),
but neither is it specified by any standard: -lsocket is a case where the
standard says "do whatever you want", and these are case where a standard is
pretty much useless.

The point is that if you have libfrobnicate.a, which may have been build
with network support or not, on an unknown system where libsocket.a may
exist or not, you have absolutely no way to predict whether you must put
-lsocket or you must not.

> I would argue pkg-config at best changes nothing, and more commonly
> makes matters worse.

Could you be more specific about "commonly makes matters worse"? Give some
concrete examples of situations that would work better without pkg-config?

As for "as best changes nothing", I would argue against that: the .pc file
for the libfrobnicate.a above would have told you whether you require
-lsocket or not, and since -l is a standard flag, it would have worked not
only for the system's compiler, but also for any compatible compiler.

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

Yes, it is possible, but I do not agree it makes things better. It helps in
some borderline cases, but it makes things globally more complex, and thus
raises the barrier to get things working right in the first place.

You get exactly the same amount of reliability by wrapping the third-party
compiler in a shell script that recognize the options, and thus turns it
into a drop-in replacement of the system's compiler. This approach has the
merit of working with any automatic configuration system.

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

Just a few major ones would fit nicely and support your discourse.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100224/10590390/attachment.pgp>