registry team mailing list archive

[Bug Watch Updater <336634@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 14 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=4738.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2005-10-10T12:20:13+00:00 Mikhail-zabaluev wrote:

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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/0

------------------------------------------------------------------------
On 2005-11-21T21:33:54+00:00 Mikhail-zabaluev wrote:

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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/1

------------------------------------------------------------------------
On 2005-11-21T22:41:30+00:00 Mikhail-zabaluev wrote:

Created an attachment (id=3860)
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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/2

------------------------------------------------------------------------
On 2007-01-24T06:33:17+00:00 Rdieter-math wrote:

Created an attachment (id=8494)
fix up check/check-requires-private too

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/14

------------------------------------------------------------------------
On 2007-02-06T11:36:43+00:00 Matthias Clasen wrote:

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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/15

------------------------------------------------------------------------
On 2007-03-29T13:17:28+00:00 Freedesktop-tevp wrote:

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?

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/16

------------------------------------------------------------------------
On 2007-03-29T19:30:49+00:00 Matthias Clasen wrote:

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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/17

------------------------------------------------------------------------
On 2007-10-19T11:13:20+00:00 Dbn-lists wrote:

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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/18

------------------------------------------------------------------------
On 2007-10-19T12:49:09+00:00 Dbn-lists wrote:

Created an attachment (id=12126)
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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/19

------------------------------------------------------------------------
On 2007-12-18T15:58:12+00:00 Dbn-lists wrote:

Created an attachment (id=13197)
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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/20

------------------------------------------------------------------------
On 2007-12-18T16:00:31+00:00 Dbn-lists wrote:

Created an attachment (id=13198)
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.

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/21

------------------------------------------------------------------------
On 2008-11-01T22:18:52+00:00 Leio-gentoo wrote:

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...?

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/22

------------------------------------------------------------------------
On 2009-01-24T05:53:19+00:00 Vincent Untz wrote:

Was hit by this in openSUSE too :-)

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/23

------------------------------------------------------------------------
On 2009-01-30T08:33:19+00:00 Vincent Untz wrote:

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 ;-)

Reply at: https://bugs.launchpad.net/pkg-config/+bug/336634/comments/24


** Changed in: pkg-config
   Importance: Unknown => Medium

-- 
libxxf86vm-dev should depend on libxext-dev
https://bugs.launchpad.net/bugs/336634
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for pkg-config.