[FFmpeg-devel] usage of Requires.private in *.pc files
Wed Nov 12 12:49:18 CET 2008
On Wed, 2008-11-12 at 10:28 +0000, M?ns Rullg?rd wrote:
> Reinhard Tartler wrote:
> > Thinking a bit more about it, it seems to me that Libs.private is rather
> > pointless. See for reference pkg-config(5):
> > Libs.private: This line should list any private libraries in use.
> > Private libraries are libraries which are not exposed through
> > your library, but are needed in the case of static linking.
> > Static linking is only done when ffmpeg is compiled statically. but the
> > line is only inserted if ffmpeg is compiled as a shared library.
> It was added by this commit:
> The submitter of that patch was quite adamant this was the One True Way,
> quoting the very same bit of scripture as you to prove it. Discussion
> here: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/67866
The submitter was saying that Libs.private was the correct field to use,
basically the same thing as was said in this thread.
The "pointless" part is about the effect of the conditional
shared/static logic in FFmpeg. According to the thread above that was
added to make pkg-config return the flags needed for static linking
*even when not asked to link statically* if only static libraries are
built. If you have both a shared and a static library then Libs.private
is the only correct alternative to make pkg-config return the correct
answer for both shared and static link case (which need different
flags). The logic to move the flags to Libs when building static only
means pkg-config always returns the static flags.
_If_ you assume that both static and shared library cannot be installed
at the same time, then _that_ makes Libs.private kind of pointless;
either you have a shared library in which case you can ignore
Libs.private which is needed for static only, or you have a static
library in which case you can put the flags to Libs just as well as
they'll always be unconditionally needed.
More information about the ffmpeg-devel