|Summary:||--exists processing Requires.private creates unnecessary depencencies|
|Product:||pkg-config||Reporter:||Mikhail Zabaluev <mikhail.zabaluev>|
|Component:||src||Assignee:||Tollef Fog Heen <tfheen>|
|Status:||RESOLVED MOVED||QA Contact:|
|Priority:||high||CC:||dmacks, freedesktop, jjk, leio, rdieter, vuntz|
|i915 platform:||i915 features:|
a quick fix
fix up check/check-requires-private too
Simpler fix to just toggle ignore_requires when using --exists
Handle Requires and Requires.private separately from main.c
Tests for the case of a missing Requires package
Description Mikhail Zabaluev 2005-10-10 12:20:13 UTC
Carried over from the discussion on bug #3097. Checking depencencies listed in the Requires.private field when performing --exists effectively creates buildtime dependencies that are unnecessary for pure dynamic builds. For example, cairo now lists libpng12 in Requires.private, and every configure script that tests for cairo now fails if libpng12.pc is not present, even though libpng is not needed for all-dynamic linking. Proposed solution: --exists should also ignore Requires.private unless --static flag has been specified.
Comment 1 Mikhail Zabaluev 2005-11-21 21:33:54 UTC
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.
Comment 2 Mikhail Zabaluev 2005-11-21 22:41:30 UTC
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.
Comment 3 Rex Dieter 2007-01-24 06:33:17 UTC
Created attachment 8494 [details] [review] fix up check/check-requires-private too
Comment 4 Matthias Clasen 2007-02-06 11:36:43 UTC
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.
Comment 5 Tom Parker 2007-03-29 13:17:28 UTC
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?
Comment 6 Matthias Clasen 2007-03-29 19:30:49 UTC
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.
Comment 7 Dan Nicholson 2007-10-19 11:13:20 UTC
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.
Comment 8 Dan Nicholson 2007-10-19 12:49:09 UTC
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.
Comment 9 Dan Nicholson 2007-12-18 15:58:12 UTC
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.
Comment 10 Dan Nicholson 2007-12-18 16:00:31 UTC
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.
Comment 11 Mart Raudsepp 2008-11-01 22:18:52 UTC
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...?
Comment 12 Vincent Untz 2009-01-24 05:53:19 UTC
Was hit by this in openSUSE too :-)
Comment 13 Vincent Untz 2009-01-30 08:33:19 UTC
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 ;-)
Comment 14 Jan Niklas Hasse 2013-11-26 18:53:20 UTC
Any news on this?
Comment 15 Dan Nicholson 2013-12-14 16:48:02 UTC
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.
Comment 17 GitLab Migration User 2018-08-25 12:54:57 UTC
-- 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.