Bug 4738

I think this needs some more clarification.
This problem arises in distributions, where it's common to separately package
files needed at build time only. Thus, a .pc file for a private dependency may
not be present (as it's in the appropriate -devel or -DEV package), even though
the library files are there.

Created attachment 3860 [details] [review]
a quick fix

This patch disables processing of Requires.private in all modes unless --static
option is in effect.
Right now, I'm not so accustomed with the code as to make more discriminate
changes.

P.S. There is an imperfection in the parser code that this patch also amends.

Created attachment 8494 [details] [review]
fix up check/check-requires-private too

Tollef, any chance you can look at this patch soon ? 
People really want me to fix this in Fedora, but I really don't want to see diverging dependency resolution between upstream and downstream pkg-config,
so I'd be happy if this patch could go in.

If cairo has libpng12 in it's Requires.private, then this should imply that cairo both requires libpng12 header files in it's public headers, and therefore needs it for compiling individual files *and* has a library dependancy on it. If OTOH, cairo only has a library dependancy on libpng12, and not any dependancies in it's public headers on libpng12, then shouldn't that be a Libs.private not Requires.private?

Tom, cairo uses Requires.private instead of Libs.private since the private dependency has a pc file. 

I have put the patch in the Fedora package now, since it doesn't look as if Tollef will act on them anytime soon.

This patch unfortunately breaks the behavior added in 0.21 where the Cflags are always listed from Requires.private packages, irrespective of --static.

http://lists.freedesktop.org/archives/xorg/2007-October/029427.html

Maybe another ignore_private_requires boolean can be added and set when --exists is used.

Created attachment 12126 [details] [review]
Simpler fix to just toggle ignore_requires when using --exists

I believe this patch does the right thing. When --exists is in use, it toggles the ignore_requires boolean to TRUE. The parsing will then skip Requires and Requires.private. I checked that the Requires.private behavior for --cflags and --libs worked correctly with and with --static, too.

Created attachment 13197 [details] [review]
Handle Requires and Requires.private separately from main.c

I realized that the previous patch still did not fix the case where a Requires.private was missing and the user requested --libs. This patch adds a new global and helper functions for ignoring Requires.private in addition to the Requires helper functions from the previous patch.

Now, Requires are ignored from main.c unless the user has requested Cflags or Libs. The Requires.private field is ignored unless the user has requested Cflags or static Libs.

Created attachment 13198 [details] [review]
Tests for the case of a missing Requires package

Here are some new tests which check the behavior of pkg-config with various requests when a package from Requires is missing. Along with the previous patch and the earlier patch to check-requires-private, all tests pass.

Apparently the link referenced in comment #7 goes to an unrelated post these days, probably due to some mailing list management changes. I'm quite sure the following thread was meant instead, after digging around 2007-October full archive to find it:

http://lists.freedesktop.org/archives/xorg/2007-October/028961.html

The most discussion on the subject is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340904 that tries to explain why cflags need to recursively be pulled in for even Requires.private. I'm not particularly agreeing with that, but I see it is necessary as long as there is no way to specify header-only requirements separately, which in turn might be an overkill and as cflags doesn't really imply any extra dynamic dependencies I can live with it.

I found out this bug bites us hard in Gentoo Linux as well, especially in conjunction with xorg proto packages that only provide headers (as for regular packages we don't separate them into regular and -dev packages as is the case in comment #1). Our packages are all built from source even for users, and build time dependencies are handled separately from runtime dependencies, whereas only build time dependencies can be removed after installing (it involves compiling for users), or not installed at all for the case of prebuilt binary packages. So the current state in vanilla pkg-config-0.23 means we'd have to build-time depend on many xorg proto header-only packages for all gtk+ using packages (for example) because pkg-config --exists gtk+-2.0 pulls in for example renderproto via gtk+-2.0 -> cairo -> xrender -> renderproto (latter two being only Requires.private). A fix for this bug would avoid that, and I will need to include such a patch in Gentoo as well, differing from vanilla similar to Fedora.

Please give some attention to this bug, thank you.

Somewhat unrelated to that, but where does pkg-config version control system reside these days...?

Was hit by this in openSUSE too :-)

Some notes from Tollef at http://err.no/personal/blog/tech/2008-03-25-18-07_pkg-config,_sonames_and_Requires.private

I still disagree, though ;-)

Any news on this?

The way I see it is that this can't be fixed in the current fields without breaking the expected behavior. So, my plan is to get a version 1 spec out that describes the exact semantics pkg-config has now. Then, I plan on introducing variants for Requires - module(Cflags) and module(Libs). This would allow you to narrow what you want to gather on module collection. To fix this bug, by specifying "Requires.private: foo(Libs)", pkg-config would be allowed to completely drop the need for foo.pc in the typical shared case because you've informed it that you do not need the Cflags.

Unfortunately, it's been a busy year for me and I haven't had a ton of time to work on pkg-config. I did prototype the above and it worked well.

See also Bug #105572.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pkg-config/pkg-config/issues/28.