Requires.private behaviour and usage.

Nicolas Chauvet kwizart at
Fri Feb 27 08:18:46 PST 2009


As reported in this bug:
Problem have been reported against the Requires.private behaviour in pkgconfig

Looking at previous report about Requires.private, it seems that it
was already reported on this list:
But was incorrectly associated with this bug:

The side effect that have been identified is that, even if the
"private libraries" aren't required when building against shared
libraries, pkgconfig will search for their .pc file for the CFLAG
field, assuming it will be needed all the time.
Most of the time, having CFLAGS from Requires.private added shouldn't
be needed at all, because public headers aren't necessarily exposed to
their Requires.private dependencies. But in the case of every
precompiled distribution, it requires more packages than what will be
needed in order to get the package to build.

One can still say, the problem is about how project use the
Requires.private features:
for example :
But when projects want to move from Lib.private to Requires.private so
the libraries dependencies will be handled by the  pkg-config
abstraction system, they ends to all be exposed to this problem as
they assume the behaviour would be the same. Whereas it is not (it
will add unneeded requires when not using static linking).

That last point is also a documentation problem.
Since the Requires.private isn't well documented at this step, it ends
for project to imagine the behaviour.
Of course the documentation is wrong, because the Requires.private
behaviour without using -static is counter intuitive.

So, what I would propose as a fix would be to deprecate
Requires.private alone, and to split Requires.Cflags from
Requires.private (it will assume that Requires.private behaviour will

What do you think ?

Nicolas (kwizart)

More information about the pkg-config mailing list