[FFmpeg-devel] [PATCH] define private libs properly in pkgconfig files
Fri May 9 07:57:47 CEST 2008
Aurelien Jacobs wrote:
> Anssi Hannula wrote:
>> j at v2v.cc wrote:
>>> On Thu, 2008-05-08 at 04:46 +0300, Anssi Hannula wrote:
>>>> If you are linking statically, you have to use '--static' option of
>>>> pkg-config. Then all libraries are printed.
>>> how can i do that with ?PKG_CHECK_MODULES?
>>> pkg-config does not seam to check or know if only static linking
>>> is possible. by default ffmpeg does not install shared libs.
>> Indeed, PKG_CHECK_MODULES does not know that.
> And thus, PKG_CHECK_MODULES have to be fixed to support static libs.
> (aren't you starting to feel the autotools ugliness ? ;-)
>> So I guess the way to make it behave correctly is indeed to not make
>> $name-uninstalled.pc use Libs.private and only make $name.pc use
>> Libs.private when the shared library is created.
> That's wrong. Both $name-uninstalled.pc and $name.pc can be used
> to link with static as well as shared libs if both are built.
$name-uninstalled.pc can only be used to link statically, as it
hardcodes the static library name.
> Current .pc files seems to be OK. The actual bug is in
Unfortunately AFAICS that would not be easy to fix. PKG_CHECK_MODULES
uses "pkg-config --libs", and pkg-config doesn't do anything else than
just parse .pc files. Parsing libraries from Libs and checking whether
they exist as shared libraries would seem ugly.
This issue has been discussed in pkg-config mailinglist. The issue is
acknowledged, but they do not have any good immediate solutions either:
Basically the suggestions are
a) Output different .pc depending on whether shared libs are created.
b) Output one .pc for shared and one .pc for static library.
I'm in favor of implementing 'a' in ffmpeg, which is what my last patch
More information about the ffmpeg-devel