libxxf86vm-dev should depend on libxext-dev
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pkg-config |
Unknown
|
Medium
|
|||
pkg-config (Debian) |
Fix Released
|
Unknown
|
|||
pkg-config (Fedora) |
Won't Fix
|
High
|
|||
pkg-config (Ubuntu) |
Triaged
|
Low
|
Unassigned |
Bug Description
Binary package hint: libxxf86vm-dev
When you install libxxf86vm-dev and don't have libxext-dev installed you'll get the following error message when trying to use the .pc file:
jhasse@hardy:~$ pkg-config xxf86vm --cflags --libs
Package xext was not found in the pkg-config search path.
Perhaps you should add the directory containing `xext.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xext', required by 'Xxf86vm', not found
jhasse@hardy:~$
In freedesktop.org Bugzilla #4738, Mikhail-zabaluev (mikhail-zabaluev) wrote : | #1 |
In freedesktop.org Bugzilla #4738, Mikhail-zabaluev (mikhail-zabaluev) wrote : | #2 |
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.
In Debian Bug tracker #340904, Loïc Minier (lool) wrote : Inclusion of .private's "-I"s | #3 |
Package: pkg-config
Version: 0.20-1
Severity: normal
Hi,
(we had this discussion on IRC already)
It might be nice to use "-I" of the .private pseudo-headers in .pc
files each time some -I flags are requested, eg. not only for static
builds.
As I understand it, the introduction of .private pseudo-headers was
meant to lower the number of ELF DEPENDS as caused by the use of "-l"
flags when linking objects with the help of pkg-config.
These flags are only needed when linking statically, and pkg-config
offers a "--static" flag to choose the type of linking one wants.
The problems arise for header files of a package distributing a .pc
file when these are including third party headers; for example, the
vte headers include the Atk, Pango, Gtk and other headers.
While there might be some discussion on whether the ELF DEPENDS should
reflect these header inclusions, it seems quite safe to assume that all
-I, from private or non private headers, should be present when
building objets, for static linking or not.
Bye,
--
Loïc Minier <email address hidden>
In Debian Bug tracker #340904, Loïc Minier (lool) wrote : | #4 |
On sam, nov 26, 2005, Loic Minier wrote:
> (we had this discussion on IRC already)
More bits, the new information here is that people involved in
pkg-config think that using headers of another lib in your headers
means you have a public dep on this other lib, and that will result in
an ELF dep. It also clarifies that the improvement is because of the
removal of the static flags which caused dynamic deps, and won't
improve gtk-ish/gnome-ish libs.
21:55 < lool> vorlon: if you have two minutes, could you please send a word to
<http://
21:57 < Q_> lool: Still waiting for a fix so I can build gtk-sharp2.
21:58 < lool> Q_: well, I'm still waiting for a consensus to be reached, I
think the stronger opinion was to add only -Is from private fields
21:58 < lool> but this is all too borderline for me to take the decision, one
way or the other
22:00 < Q_> Mithrandir: Around?
22:01 < lool> Q_: BTW, I filed #340904 to track the story
22:02 < vorlon> lool: what word are you looking for? :)
22:03 < lool> vorlon: the kind of word carrying final-person opinion (eg where
I don't relay opinions from third parties :)
22:04 < lool> this is really a pkg-config design question for me, and the
you or Mithrandir or who ever feels he knows what is correct
22:05 < vorlon> lool: well, Mithrandir and I seem to disagree here on what the
the other is not. :)
22:06 < Q_> lool: And nothing happened to it yet.
22:06 < lool> vorlon: exactly, and since I'm not strongly convinced one way or
the other, I can't represent either party in the discussion O:-)
22:08 < vorlon> lool: well, I don't see much point in trying to argue the
not fair to the vte maintainers, and it's not a very effective
22:10 < lool> vorlon: well, I wanted your take on the situation to vte's
short of arguments what ever camp vte's upstream picks
22:10 * lool bravely goes telling vte maintainer that we've pulled them in a
mid-term problem
22:12 < Mithrandir> Q_: yes
22:13 < vorlon> lool: I don't think vte upstream is going to pick the "I'll let
my software continue to be broken" camp
22:14 < lool> exactly
22:14 < Q_> Mithrandir: So, did you have some time to think about the problem,
and the best way to solve it?
22:14 < dilinger> i wish i could admin some AIX machines
22:15 < dilinger> i bet it would cause me to get a lot less frustrated when i'm
In Debian Bug tracker #340904, Loïc Minier (lool) wrote : | #5 |
(End of the IRC discussion:)
22:42 < Q_> But it's the right way to do it, just because they can relink
22:43 < vorlon> Q_: actually, IME they'll use any excuse to change sonames
22:44 < Q_> They do?
22:44 < Q_> Then I don't see why they would have a problem with it.
22:46 < Q_> Mithrandir: Do you have any idea around what time jamesh is around
22:46 < Mithrandir> if you have App A, lib B and lib C. B links to C. A uses
22:46 < Mithrandir> Q_: he lives in western .au, so he might be around in a
22:47 < lool> Mithrandir: ah you make me think of something really painful,
there are weird macros accessing structs in headers
22:48 < lool> so including headers of lib C in lib B might be enough for app A
to get smoe code dependent on the structs in C added to it and
hence crashing with a newer C
22:49 < Mithrandir> I'm wondering if my case will work correctly if A is linked
22:49 < Q_> Mithrandir: I don't think you can keep A working without also
22:49 < lool> I'm not sure I have a real life example, but I think the fact
it's possible might be enough to try to guard against it
22:56 < vorlon> Mithrandir: in that scenario, why is it *not* a bug for B to be
22:57 < Q_> Mithrandir: A will get linked to 2 lib C's in that case.
22:57 < Mithrandir> Q_: that's fine if they have versioned symbols, AIUI?
22:57 < vorlon> Mithrandir: if the headers from C are being included into B, it
and that just tells me C's headers should be more granular and
B shouldn't be linking to C either.
22:58 < vorlon> hmm, ok. possibility: C makes ABI changes to parts that aren't
22:59 < Mithrandir> vorlon: I didn't talk about headers, I talked about
22:59 < Mithrandir> I was wondering if you could make it work or not.
22:59 < Q_> Mithrandir: If A include's C's headers, it should link to it itself.
22:59 < vorlon> oh. then I guess you're only talking about the usual
23:00 < Mithrandir> vorlon: yes, I might very well be, and that works, doesn't
23:00 < Mithrandir> Q_: yes, I meant to write that, but didn't
23:00 < vorlo...
In Debian Bug tracker #340904, Loïc Minier (lool) wrote : Re: Bug#343711: gdk-x11-2.0.pc spreads library dependencies needlessly | #6 |
block #343711 by #340904
thanks
On sam, déc 17, 2005, J.H.M. Dassen (Ray) wrote:
> Yes. I'm going by this guideline from /usr/share/
> "Generally, if include another library's headers in your own, it's a public
> dependency and not a private one.".
Yes, that's part of the discussion we had with the pkg-config
maintainer, and that's what he suggests indeed.
However, Gdk includes Pango, which in turn includes Xft, Freetype; Gdk
also includes cairo, which in turn includes Fontconfig and Freetype,
etc. I suppose that would make these libs public dependencies of Gdk
too, following the same logic.
I think I'm going to let this change be blocked by the pkg-config
change I pointed at, until then it wouldn't be wise to introduce build
failures.
The best thing I wish is that someone with experience in ABI / API
handling, pkg-config, and shared libraries in general writes a guide to
handle situations such has: 1/ how to check a .la file is correct 2/
what to put in .pc files.
Bye,
--
Loïc Minier <email address hidden>
In Debian Bug tracker #340904, Loïc Minier (lool) wrote : block 346039 with 340904 | #7 |
# Automatically generated email from bts, devscripts version 2.9.10
block 346039 with 340904
In Debian Bug tracker #340904, Steve Langasek (vorlon) wrote : Re: Bug#349318: fixed in xft 2.1.8.2-1 | #8 |
reopen 349318
block 349318 by 340904
thanks
> * Add 001_no_
> Langasek that causes xft.pc not to export freetype or xrender as part of
> the interface, but hide them in Requires.private instead (closes: #349318)
The patch is:
Index: libXft-
=======
--- libXft-
+++ libXft-
@@ -6,7 +6,7 @@
Name: Xft
Description: X FreeType library
Version: @VERSION@
-Requires: xproto, xrender, fontconfig, freetype2
-Requires.private: xrender, fontconfig, freetype2
+Requires: xproto, fontconfig
+Requires.private: xrender, freetype2
Cflags: -I${includedir}
Libs: -L${libdir} -lXft
This won't work because of the aforementioned bug #340904:
$ grep -h include include/X11/Xft/*.h
#include <X11/Xfuncproto.h>
#include <stdarg.h>
#include <ft2build.h>
#include FT_FREETYPE_H
#include <fontconfig/
#include <X11/extensions
#include <X11/Xfuncproto.h>
/* #include <X11/Xosdefs.h>*/
#include <X11/Xft/
$
Both the xrender and freetype2 headers are included in Xft/Xft.h, and types
from both of these headers are exported in the Xft API -- so any software
using Xft.h needs to be able to find these other headers as well.
Currently, pkg-config does *not* pass cflags from packages listed in
Requires.private when called as pkg-config --cflags <foo>.
So far, the maintainer has resisted changing pkg-config to export cflags
(which should really be called cppflags...) from Requires.private due to a
fallacious argument regarding the nature of "private" dependencies. There
are three real use cases for libraries which depend on other libraries:
- the library intentionally exports the API and ABI of its dependencies when
linked to, and therefore both the ldflags and the cflags of its
dependencies should be exported by pkg-config in all cases[1]
- the library intentionally includes headers from dependencies in its own
headers in order to inherit type definitions, but these definitions are
not intended for direct consumption by users of this library alone;
therefore pkg-config must export the cflags from dependencies in all
cases, but the ldflags only when linking statically
- the library's API includes no headers from its dependencies; pkg-config
needs to export the ldflags of private dependencies when statically
linking but not when dynamically linking, and should *never* need to
export the cflags of these headers.
Please note that today, the handling of Requires.private in pkg-config maps
to *none* of these cases -- I can't think of a single situation in which
cflags of dependencies are needed when statically linking, and not needed
when dynamically linking! Instead, the Requires.private handling is
adequate for the third case; handling of Requires is correct for the first
case; and there is no combination of options that is appropriate for the
second case.
This is unfortunate, because there are a great many packages that are
inheriting de...
In Debian Bug tracker #340904, James Henstridge (jamesh) wrote : Re: [Steve Langasek] Bug#340904: Bug#349318: fixed in xft 2.1.8.2-1 | #9 |
Tollef Fog Heen wrote:
>Hi, any chance you could comment on this? I'm somewhat inclined to
>agree with Steve, but you know this stuff better than I do, so I'd
>value a second opinion.
>
>Also, if there's anything unclear or anything, please do mail Steve
>(and the bug) with me in Cc.
>
>
[snip]
>
>
>Both the xrender and freetype2 headers are included in Xft/Xft.h, and types
>from both of these headers are exported in the Xft API -- so any software
>using Xft.h needs to be able to find these other headers as well.
>Currently, pkg-config does *not* pass cflags from packages listed in
>Requires.private when called as pkg-config --cflags <foo>.
>
>
The fact that the headers are included makes them part of the _public_
ABI of Xft. There are Xft functions that accept or return types defined
in the Xrender and freetype2 headers.
If Xft is updated to a new version of either of those libraries such
that those types are defined differently (altered struct layout,
different type sizes, etc), then the app also needs to be updated to the
new version.
>So far, the maintainer has resisted changing pkg-config to export cflags
>(which should really be called cppflags...) from Requires.private due to a
>fallacious argument regarding the nature of "private" dependencies. There
>are three real use cases for libraries which depend on other libraries:
>
>- the library intentionally exports the API and ABI of its dependencies when
> linked to, and therefore both the ldflags and the cflags of its
> dependencies should be exported by pkg-config in all cases[1]
>
>
Yep, this is the use case addressed by "Requires".
>- the library intentionally includes headers from dependencies in its own
> headers in order to inherit type definitions, but these definitions are
> not intended for direct consumption by users of this library alone;
> therefore pkg-config must export the cflags from dependencies in all
> cases, but the ldflags only when linking statically
>
>
Changes to type definitions _do_ change the ABI. If library A uses
library B's types in its ABI, then it's ABI will break if library B
changes those types. An app using library A should definitely record
the version of library B being used.
>- the library's API includes no headers from its dependencies; pkg-config
> needs to export the ldflags of private dependencies when statically
> linking but not when dynamically linking, and should *never* need to
> export the cflags of these headers.
>
>
This is the use case for "Requires.private". If the dependency doesn't
form part of the library's API, then it obviously doesn't require direct
linkage and is private.
>Please note that today, the handling of Requires.private in pkg-config maps
>to *none* of these cases -- I can't think of a single situation in which
>cflags of dependencies are needed when statically linking, and not needed
>when dynamically linking!
>
The cflags of dependencies listed in "Requires.private" are not included
for either dynamic or static modes of pkg-config, so maps to case 3
quite well.
Consider the following two .pc files. First "foo.pc":
Name: foo
Description: foo
Version: 1.0
Cflags: foo-cflags
...
In Debian Bug tracker #340904, Steve Langasek (vorlon) wrote : | #10 |
Hi James,
Nice to meet you!
On Wed, Feb 08, 2006 at 07:28:39PM +0800, James Henstridge wrote:
> Tollef Fog Heen wrote:
> >Hi, any chance you could comment on this? I'm somewhat inclined to
> >agree with Steve, but you know this stuff better than I do, so I'd
> >value a second opinion.
> >Also, if there's anything unclear or anything, please do mail Steve
> >(and the bug) with me in Cc.
> [snip]
> >Both the xrender and freetype2 headers are included in Xft/Xft.h, and types
> >from both of these headers are exported in the Xft API -- so any software
> >using Xft.h needs to be able to find these other headers as well.
> >Currently, pkg-config does *not* pass cflags from packages listed in
> >Requires.private when called as pkg-config --cflags <foo>.
> The fact that the headers are included makes them part of the _public_
> ABI of Xft. There are Xft functions that accept or return types defined
> in the Xrender and freetype2 headers.
> If Xft is updated to a new version of either of those libraries such
> that those types are defined differently (altered struct layout,
> different type sizes, etc), then the app also needs to be updated to the
> new version.
Ok, here's the problem with this argument.
Yes, if one of the freetype types that's used in Xft/Xft.h changes, that is
an ABI change... *in libXft* -- that's why we care about it! Because it's
an ABI change in libXft, the soname of *libXft* should change. With the
change of libXft's soname, there's no reason an application that is a
consumer of libXft, but *not* a consumer of freetype, should care about
libfreetype *at all*.[1]
On the other hand, there are plenty of cases in which an ABI change in
libfreetype will *not* cause an ABI change in libXft. Addition or removal
of functions, addition of typedefs, or removal or changing of any typedefs
not used in libXft's ABI are all changes that should require an soname
change in libfreetype but not an soname change in libXft. The present ABI
transition in libfreetype is such a case. But because these applications
are being encouraged to link directly to libfreetype, *even though they
don't use it*, they have to care about ABI changes that should not affect
them.
The net result is that pkg-config's handling of Requires/
directly causing churn in response to ABI changes in any indirect library
dependencies, where this should be completely unnecessary on GNU/Linux
platforms. It increases the chances of segfaults or other failures from
loading two different versions of a library into memory, and correspondingly
increases the frequency with which binaries need to be rebuilt in response
to ABI changes that don't actually concern them. And it does this entirely
to support a use case which, as explained above, should not actually exist.
> >- the library intentionally includes headers from dependencies in its own
> > headers in order to inherit type definitions, but these definitions are
> > not intended for direct consumption by users of this library alone;
> > therefore pkg-config must export the cflags from dependencies in all
> > cases, but the ldflags only when linking statically
> Changes to type definition...
In Debian Bug tracker #340904, James Henstridge (jamesh) wrote : | #11 |
Steve Langasek wrote:
>>If Xft is updated to a new version of either of those libraries such
>>that those types are defined differently (altered struct layout,
>>different type sizes, etc), then the app also needs to be updated to the
>>new version.
>>
>>
>Ok, here's the problem with this argument.
>
>Yes, if one of the freetype types that's used in Xft/Xft.h changes, that is
>an ABI change... *in libXft* -- that's why we care about it! Because it's
>an ABI change in libXft, the soname of *libXft* should change. With the
>change of libXft's soname, there's no reason an application that is a
>consumer of libXft, but *not* a consumer of freetype, should care about
>libfreetype *at all*.[1]
>
>
The simple matter of fact is that when you ask for the Xft API in your
app (#include <Xft/Xft.h>), you also get the freetype API at the same
time. While some apps don't use it, we can't say that apps don't use
those APIs in the general case. Until we have a widely used way to
express dependencies at that granularity, you need to look at the
library level.
>On the other hand, there are plenty of cases in which an ABI change in
>libfreetype will *not* cause an ABI change in libXft. Addition or removal
>of functions, addition of typedefs, or removal or changing of any typedefs
>not used in libXft's ABI are all changes that should require an soname
>change in libfreetype but not an soname change in libXft. The present ABI
>transition in libfreetype is such a case. But because these applications
>are being encouraged to link directly to libfreetype, *even though they
>don't use it*, they have to care about ABI changes that should not affect
>them.
>
>
They are using it in conjunction with the Xft API. There is no clear
separation between the Xft APIs that use it and those that don't. Of
course, an app that only depends on Xft indirectly and doesn't use Xft's
APIs doesn't need direct linkage to freetype.
>The net result is that pkg-config's handling of Requires/
>directly causing churn in response to ABI changes in any indirect library
>dependencies, where this should be completely unnecessary on GNU/Linux
>platforms. It increases the chances of segfaults or other failures from
>loading two different versions of a library into memory, and correspondingly
>increases the frequency with which binaries need to be rebuilt in response
>to ABI changes that don't actually concern them. And it does this entirely
>to support a use case which, as explained above, should not actually exist.
>
>
The "app links to multiple versions of library A" problem is quite easy
to diagnose, and also makes it clear that an app needs to be rebuilt if
the old library version is removed (i.e. the app doesn't start). The
"app depends on the structure layout of the old version of library A but
doesn't directly link to library A" is more difficult to catch.
It sounds like your argument is that "Xft shouldn't expose the freetype
API". Given that this isn't the case, the direct linkage makes sense.
The freetype change in this case might not break many Xft using apps,
but that won't necessarily be the case next time this type of situation
occurs.
>...
In Debian Bug tracker #340904, Steve Langasek (vorlon) wrote : | #12 |
On Thu, Feb 09, 2006 at 06:59:02PM +0800, James Henstridge wrote:
> Steve Langasek wrote:
> >>If Xft is updated to a new version of either of those libraries such
> >>that those types are defined differently (altered struct layout,
> >>different type sizes, etc), then the app also needs to be updated to the
> >>new version.
> >Ok, here's the problem with this argument.
> >Yes, if one of the freetype types that's used in Xft/Xft.h changes, that is
> >an ABI change... *in libXft* -- that's why we care about it! Because it's
> >an ABI change in libXft, the soname of *libXft* should change. With the
> >change of libXft's soname, there's no reason an application that is a
> >consumer of libXft, but *not* a consumer of freetype, should care about
> >libfreetype *at all*.[1]
> The simple matter of fact is that when you ask for the Xft API in your
> app (#include <Xft/Xft.h>), you also get the freetype API at the same
> time. While some apps don't use it, we can't say that apps don't use
> those APIs in the general case.
You're right, we can't. But as library authors/
whether we intend to *support* such abuses of the API. You can get a valid
prototype of fprintf() on Linux by doing #include <sql.h> (from UnixODBC)
instead of #include <stdio.h>, too, and we don't know that there isn't
anybody relying on that -- but if they do, and they complain about it
breaking, they are cordially invited to blow it out their ass. ;)
The current policy of pkg-config prevents library authors from making their
own choices about whether to support such API abuses on the part of
applications. I don't think pkg-config should be imposing policies which
prevent library authors from deciding what uses of their headers they intend
to support. The current behavior of pkg-config *ensures* that the API
abuses you describe will work, because use of Requires means they'll get the
ldflags as well as the cflags; that makes pkg-config as it stands pretty
suboptimal for anyone who *doesn't* want to get supporting their lib
dependencies as part of the public API.
> >On the other hand, there are plenty of cases in which an ABI change in
> >libfreetype will *not* cause an ABI change in libXft. Addition or removal
> >of functions, addition of typedefs, or removal or changing of any typedefs
> >not used in libXft's ABI are all changes that should require an soname
> >change in libfreetype but not an soname change in libXft. The present ABI
> >transition in libfreetype is such a case. But because these applications
> >are being encouraged to link directly to libfreetype, *even though they
> >don't use it*, they have to care about ABI changes that should not affect
> >them.
> They are using it in conjunction with the Xft API. There is no clear
> separation between the Xft APIs that use it and those that don't. Of
> course, an app that only depends on Xft indirectly and doesn't use Xft's
> APIs doesn't need direct linkage to freetype.
They are using data types defined by freetype in conjunction with the Xft
API. If they're using function calls from freetype without including
freetype headers, they didn't get that idea from Xft's documentation or by...
In Debian Bug tracker #340904, Tollef Fog Heen (tfheen) wrote : Bug#340904: fixed in pkg-config 0.21-1 | #13 |
Source: pkg-config
Source-Version: 0.21-1
We believe that the bug you reported is fixed in the latest version of
pkg-config, which is due to be installed in the Debian FTP archive:
pkg-config_
to pool/main/
pkg-config_
to pool/main/
pkg-config_
to pool/main/
pkg-config_
to pool/main/
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Tollef Fog Heen <email address hidden> (supplier of updated pkg-config package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Wed, 16 Aug 2006 21:11:21 +0200
Source: pkg-config
Binary: pkg-config
Architecture: source i386
Version: 0.21-1
Distribution: unstable
Urgency: low
Maintainer: Tollef Fog Heen <email address hidden>
Changed-By: Tollef Fog Heen <email address hidden>
Description:
pkg-config - manage compile and link flags for libraries
Closes: 254289 334896 340904 350176 378570
Changes:
pkg-config (0.21-1) unstable; urgency=low
.
* New upstream release
- Adds internal pkg-config package. (closes: #254289)
- Supports escaping $ rather than %. (closes: #378570)
- Always adds all cflags. (closes: #340904)
* Includes full NEWS file. (closes: #334896)
* Remove libglib2.0-dev build-deps. (closes: #350176)
Files:
e922bea83dadee
476f45fab1504a
23c25fd98789a5
59f0e1fdc7ba08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFE43EjQSs
y5+NQC2kJ4aADtb
=OwY/
-----END PGP SIGNATURE-----
In freedesktop.org Bugzilla #4738, Rdieter-math (rdieter-math) wrote : | #14 |
Created an attachment (id=8494)
fix up check/check-
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #33 |
Using pkg-config-0.21 given /usr/lib/
containing:
##############
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=
Name: foo
Description: fof Library
Version: 1.0
Requires.private: bar
Cflags: -I${includedir}
Libs: -L${libdir} -lfoo
##################
$ pkg-config --libs foo
Package bar was not found in the pkg-config search path.
Perhaps you should add the directory containing `bar.pc'
to the PKG_CONFIG_PATH environment variable
Package 'bar', required by 'foo', not found
Libs.private and Requires.private should be ignored and not be used when/if one
doesn't use
$ pkg-config --static
This has been reported upstream:
https:/
with patch supplied (testing that now myself to confirm it works as advertised).
Please consider including this patch, as it fixes a few concrete examples of
brokenness, in particular,
$ yum remove libXext-devel
$ yum install libXmu-devel
$ pkgconfig --libs Xmu
Package xext was not found in the pkg-config search path.
Perhaps you should add the directory containing `xext.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xext', required by 'Xmu', not found
since xmu.pc contains:
Requires.private: ... xext
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #34 |
oops, the example *should* be:
$ pkg-config --libs xmu
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #35 |
Created attachment 146406
update to upstream patch to fixup 'make check' behavior as well
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #36 |
A can confirm patch works as advertised.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #37 |
I'll wait a bit for Tolleef to make up his mind on the upstream bug. He said
that he would have time for pkg-config bugs in a week.
In Red Hat Bugzilla #224148, Ralf (ralf-redhat-bugs) wrote : | #38 |
I think you are vastly underestimating the severity of this bug.
* This bug basically voids Requires.Private.
* it forces developers and packagers to pollute configure scripts, rpm.spec and
build scripts with avoidable (actually bogus) hacks.
In the example above, one will have to add xext to pkg-config checks in
configure-scripts, and will have to add "BuildRequires: libXext-devel" to specs
(otherwise mock will not work).
* it breaks previously (before Requires.Private had been introduced) functional
pkg-config deps and configure scripts.
Before Requires.Private, these deps had been Requires in *.pc, therefore they
had been automatically taken into account.
Therefore, I am making this a review blocker for fc7 also would recommend you to
fix it on older Fedoras, too.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #39 |
Making this a "review blocker" is not going to force my hand.
What do you want to do next, drop pkgconfig from fedora ?
The last thing I want is a pkgconfig in fedora that diverges from upstream in
how it treats dependencies.
In Red Hat Bugzilla #224148, Ralf (ralf-redhat-bugs) wrote : | #40 |
(In reply to comment #6)
> Making this a "review blocker" is not going to force my hand.
Your decision - and fault
> What do you want to do next, drop pkgconfig from fedora ?
You'd better fix the bugs.
> The last thing I want is a pkgconfig in fedora that diverges from upstream in
> how it treats dependencies.
If upstream stuff is nonfunctional, you will not be able to avoid to apply
patches and to diverge from upstream - This is the natural movement of all
packages and should be natural to any maintainer (You already do so with other
patches in pkgconfig)
In this particular case, an alternative would be to replace all
Requires.Private: from all *.pc's - but, you don't really want this, don't you?
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #41 |
> Your decision - and fault
Oh great. So I was wrong to thing that it was Rex fault to tie a package review
to an issue that is totally unrelated to packaging ?
In Red Hat Bugzilla #224148, Mamoru (mamoru-redhat-bugs) wrote : | #42 |
*** Bug 215942 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #4738, Matthias Clasen (mclasen) wrote : | #15 |
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.
In freedesktop.org Bugzilla #4738, Freedesktop-tevp (freedesktop-tevp) wrote : | #16 |
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?
In freedesktop.org Bugzilla #4738, Matthias Clasen (mclasen) wrote : | #17 |
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.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #43 |
Fixed in 0.21-5.fc7
In freedesktop.org Bugzilla #4738, Dbn-lists (dbn-lists) wrote : | #18 |
This patch unfortunately breaks the behavior added in 0.21 where the Cflags are always listed from Requires.private packages, irrespective of --static.
http://
Maybe another ignore_
In freedesktop.org Bugzilla #4738, Dbn-lists (dbn-lists) wrote : | #19 |
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.
In freedesktop.org Bugzilla #4738, Dbn-lists (dbn-lists) wrote : | #20 |
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.
In freedesktop.org Bugzilla #4738, Dbn-lists (dbn-lists) wrote : | #21 |
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-
In freedesktop.org Bugzilla #4738, Leio-gentoo (leio-gentoo) wrote : | #22 |
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://
The most discussion on the subject is at http://
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...?
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #44 |
I'm sorry, but this fix is broken. The vanilla pkg-config behavior for Requires.private is correct, and this just makes it act like Libs.private, which is wrong because it breaks Cflags handling.
In the example given above, rpm/yum would not allow you to remove libXext-devel if libXmu-devel requires pkgconfig(xext). It would do that if the pkg-config --print-requires patch also walked Requires.private. I opened bug 426106 that has patches to fix that. After all, you actually need the headers from libXext-devel installed even if you're not linking to libXext.a. So, just making pkg-config skip Requires.private unless --static is used is wrong.
The issue of whether the .pc file should be required to be installed under certain conditions should be handled separately. That's what the freedesktop bug is about. Incidentally, I have more patches to address that issue, but that's orthogonal to this.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #45 |
It is certainly hard to argue about 'correctness' of totally unspecified and undocumented features like Requires.private.
If upstream comes up with some specification for Requires.private and a matching implementation, that would be great.
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #46 |
But there is a concrete specification and implementation.
Requires: Recursively fetch Cflags and Libs from listed dependencies. Recursively fetch Libs.private if --static is specified.
Requires.private: Recursively fetch Cflags from listed dependencies. Recursively fetch Libs and Libs.private if --static is specified.
This is what vanilla pkg-config does. What pkg-config doesn't do well is handle the non-existence of .pc files when they aren't needed. In the fdo bug, the reporter is talking about --exists. We can probably agree that pkg-config shouldn't need to recursively search for listed Requires* because we only want to know about the existence of the .pc metadata for the requested package.
In this bug, the problem is that pkg-config keeps searching for .pc files for listed Requires.private even though the user has requested a case where they're not needed: --libs. It would be better if pkg-config didn't search for the listed .pc file in this case, but having it act like Libs.private is wrong because the Cflags are always needed. Another mode is needed than ignore_private_libs to handle that correctly. In the fdo bug, I have a patch which does just that, adding a ignore_
https:/
What I'm proposing is to punt on that issue for now by making rpm add autoreqs for packages listed in Requires and Requires.private. After all, you do need the -devel package for Requires.private packages installed to actually do anything useful because you need the headers and .so links. I.e., libXmu-devel should require libXext-devel since you actually need the headers and libXext.so/.a to compile a libXmu program. While calling `pkg-config --libs xmu' shouldn't strictly need libXext-devel to be installed, it is a lower priority failure than the failure to actually compile and link a libXmu program.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #47 |
> But there is a concrete specification and implementation.
Where is that specification take from ?
man pgk-config | grep Requires.private comes up empty...
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #48 |
Btw, the specification that I'd really like to see written is not one that talks about the algorithm used for handling various pc file field (though that needs writing too), but one that would be titled "Software development using pkg-config". It would answer questions like
1) My program uses library x. What do I do ?
Answer:
CFLAGS=`pkg-config --cflags x`
LIBS=`pkg-config --libs x`
(followed by a longer explanation of how this looks in autofoo)
2) My library z installs header files which include libx headers. What do I put in my z.pc file ?
...
3) My library z uses libx internally, but does not expose libx datatypes in its public api. What do I put in my z.pc file ?
...
Etc.
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #49 |
OK, I grant you that the specification is not there, the documentation is poor, and the upstream maintainer is not responsive. Do you agree with my description of the Requires.private implementation, though? And do you agree that this patch breaks handling of --cflags with Requires.private?
I would also be willing to write such a guide if anyone can manage to get Tollef Fog Heen on board.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #50 |
Ok, I'm going to drop that patch, and you write that guide. Deal ? :-)
Just need to wait for the build system to come back...
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #51 |
Yay! Thanks, Matthias. I was thinking about writing a pkg-config(7) that explained pkg-config concepts. Maybe an html guide would be better, though.
What about the patch in bug 426106 for also outputting Requires.private with --print-requires? I think that'll be needed to avoid this type of issue from cropping up again.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #52 |
Fixed in pkgconfig-
In freedesktop.org Bugzilla #4738, Vincent Untz (vuntz) wrote : | #23 |
Was hit by this in openSUSE too :-)
In freedesktop.org Bugzilla #4738, Vincent Untz (vuntz) wrote : | #24 |
Some notes from Tollef at http://
I still disagree, though ;-)
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #53 |
(In reply to comment #11)
> I'm sorry, but this fix is broken. The vanilla pkg-config behavior for
> Requires.private is correct, and this just makes it act like Libs.private,
I can agree that keeping the original pkg-config behavior should have been made.
But now having the patch reverted in F-10 will broke near everything. Each package maintainer try to fix thing at sight which will sooner or later have a complete rebuild of the whole distro because of bugs in chain.
(example https:/
I'm not sure to understand clearly what is the original pkgconfig behavior, my understanding stop at how pkgconfig creates binary linked statically versus shared library using static library as dependency.
It seems to me that requires.private should be used when building a binary and libs.private when building a library.
Anyway... Fedora doesn't use static library that much (it means static libs aren't even build at all in the majority cases). But If the need of a static library appears, then thus library should be moved to a -static subpackage which will requires the -devel one.
That's the developer responsibility to request the -static version at build time when needed. The static version will then requires every dependencies mentioned in the pkgconfig requires.private line, and that could eventually be autorequired by rpm. But the original title of this bugreport remains valid:
The "shared object only -devel sub-package" shouldn't requires.private dependency in any cases.(but this requires.private should belong to the -static one instead). It shouldn't also fail when building shared libs or against shared libs because either no static lib is present or some requires.private .pc are missing.
I'm sorry but this bug is re-opened, we (as packages maintainers) need to know how to handle the pkg-config behavior change. Either to mass-rebuild the whole F-10 distro or to revert to the ancient pkg-config.
See this case study for example: https:/
/show_bug.
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #54 |
It's not the static libraries that make the difference. It's that we need the headers and the .so regardless. In the bug you referenced, gconf2-devel doesn't have a BR on dbus-devel, so you can remove dbus-devel without removing gconf2-devel. However, you need the dbus headers (and library) to use gconf2-devel, right? I'd argue that the package was already broken. It's not like you could have compiled and linked a GConf app without dbus-devel installed.
The right way to handle this is to Requires the things that the package needs. It's broken to not require a package where you need the -devel package. I understand that can make life tough for packagers, but the previous behavior was more frustrating for developers. Imagine trying to develop software and having to consider that the tool you're using (pkg-config) works differently on one distro than another. This effectively meant that they could not use the Requires.private feature because it broke for anyone using fedora (quite a few as you can imagine).
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #55 |
> I'm sorry but this bug is re-opened, we (as packages maintainers) need to know
> how to handle the pkg-config behavior change. Either to mass-rebuild the whole
> F-10 distro or to revert to the ancient pkg-config.
I don't see how a mass rebuild of the whole F10 comes even remotely into play here. Yes, it is somewhat unfortunate that pkg-config changed its behaviour in the middle of stable releases, which is why I didn't push this out eagerly, but only after other people complained about behaviour difference between F10 and rawhide.
You may have to adjust BuildRequires slightly as you build updates, that is all.
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #56 |
(In reply to comment #21)
> It's not the static libraries that make the difference. It's that we need the
> headers and the .so regardless.
No we don't. And this is exactly what the current bug report try to address.(look at the title).
Despite it should have been made in the pkgconfig directly instead.
In this case, using GConf2-devel doesn't requires dbus-devel at all as;
when building an application using GConf2-devel:
- The GConf2-devel headers doesn't use dbus headers explicitely. (it will use glib2-devel and popt-devel as shown by "grep include /usr/include/
- The app using GConf2-devel shouldn't explicitly use dbus-devel as a mandatory requirement in order to build (as it will not use dbus headers directly either).
- As we link to a shared GConf2, we only need to pass -lGConf2 and libs fetched from Requires: so we don't get undefined-
- Since We are not using headers from Requires.private in GConf2 and dependent application, the include path and definition that can eventually be present there aren't needed also. It ends that the whole cflags from Requires.private aren't needed at all( even if using pkgconfig -static.)
- It was working fine previously, and rpmlint didn't reported undefined-
Now I'm all for you to point me a case where the use of Requires.private is correct in a package as starting point; So I can understand how pkgconfig should handle it.
Just as a note. If a given -devel is installed, the .so and headers will be there, but not the static library. If a given -static library is installed, then it will requires the -devel (which will requires the .so and header).
>... In the bug you referenced, gconf2-devel doesn't
> have a BR on dbus-devel, so you can remove dbus-devel without removing
> gconf2-devel. However, you need the dbus headers (and library) to use
> gconf2-devel, right?
Nope, it was working fine previously and the bugreport started with the pkg-config updates.
> like you could have compiled and linked a GConf app without dbus-devel
> installed.
That was how it behaved previously, and it worked like a charm.
Now I want you to answear few questions:
1 - Why pkg-config should look at Requires.private when not using -static ?
2 - Why either Requires.private (and Libs.private after all) aren't emptied when --disable-static is made. (static library is disabled at build time).
3 - When both shared and static version are built and only the shared version is shipped, Why the requires of the -devel package should cover the needs of the static case ? (which will be larger than the shared only accurate requirements).
4 - When should a library use -static with pkgconfig dependencies ?
5 - When should a binary use -static with pkgconfig dependencies ?
6 - What is the correct behaviour between theses two:
Whith the pkg-config GA behaviour:
[root@kwizatz gconf]# pkg-config --cflags gconf-2.0
-I/usr/
With the current pkg-config updates behaviour:
[root@kwizatz gconf]# pkg-config --cflags gconf-2.0
-DORBIT...
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #57 |
Now that I look at gconf, I see that you're right. This case (library a uses library b internally but does not expose its datatypes) is not handled well by pkg-config. Read this guide if you want to understand pkg-config (skip to the FAQs if you want).
http://
A workaround would be to add -ldbus-1 to Libs.private and remove dbus-1 from Requires.private in gconf-2.0.pc. Or, since the GConf2 rpm doesn't even install libgconf-2.a, drop all mentions of dbus in the .pc file. A longer term solution would have to be added to pkg-config.
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #58 |
I've read the guide, but the few words about the Requires/
So what is following is what i imagine of the differences between Requires and Requires.private.
1-
Actually, if a package use the Cflags from Requires.private for the includepath. It means it will use the headers included from Requires.private. As a consequence, it will <<have to>> "use symbols" of the related libs from Requires.private. Which, if they aren't defined at build time (linking) will need to be resolved at runtime. (rpmlint on installed packages will show undefined-
(If you don't agree with this part you will have to give an example).
I don't see how a package could see some interest in linking to gconf while not linking to dbus directly.(if ever dbus headers was used in GConf2-devel which is not the case).
I could imagine source distribution like gentoo could see some interest in having such behaviour to avoid relinking to the new SOVERSION of a library, but it would fall under the dirty hack.
We (as precompiled distribution as a whole) want this case to fail at install time (instead of opening the possibility of missing symbol at runtime).
It could be possible to have exeption, but it is the common case. And we rely the fact that shared libraries are linked at build time with an appropriate SOVERSION.
2-
Then I've wondered if it has something to do with building software from a tree.
The main feature between tree vs installed software are that "private headers" start to be accessible.
So it would have been unappropriate to use Requires.private from gconf-2.0.pc instead of gconf-2.
But even in this case, there is a need to link to libs (more than ever actually). And fetching both Cflags and libs is exactly the same behaviour as Requires:). So maybe the Requires line of a given *-(installed).pc can be different than *-(uninstalled).pc, but it still doesn't explain the different usage of Requires.private versus Requires
3-
Now what is misleading (see http://
The previous case was more or less rare cases, whereas this is a way more common. When a binary is aimed to be portable on any given GNU/Linux distro it may links against a static version of a library. But such library will only contain symbol of itself, hence there is a need for the static linker to search for its dependency also. Here is what would Requires.private aimed for.
It helps the linker to find symbols needed by a given static library. If only a shared library exist, it stop to the Libs. If it is a static library, then it pick Requires.private in the related .pc file and so on.
Then pkgconfig could look at some environment value to say when both static version and shared version exist which ones to pick. and eventually, which versioned symbol (like libresolv.so.2(...
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #59 |
The common case where one library uses datatypes from another:
$ cat /usr/lib/
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=
Name: cairo
Description: Multi-platform 2D graphics library
Version: 1.6.4
Requires.private: freetype2 >= 9.7.3 fontconfig libpng12 xrender >= 0.6 x11 pixman-1 >= 0.10.0
Libs: -L${libdir} -lcairo
Libs.private: -lz -lz -lm
Cflags: -I${includedir}
I'm writing a cairo app, so I want to link it to libcairo. However, in order to compile my app, it also needs to be get the Xrender headers and link to libXrender. Now, I could directly link my app to libXrender, but since I don't use any Xrender symbols, it's extra baggage. The linker will still resolve all the symbols at build time because libXrender is marked with a a DT_NEEDED tag in libcairo.
$ readelf -d /usr/lib/
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libfreetype.so.6]
0x00000001 (NEEDED) Shared library: [libfontconfig.
0x00000001 (NEEDED) Shared library: [libpng12.so.0]
0x00000001 (NEEDED) Shared library: [libXrender.so.1]
0x00000001 (NEEDED) Shared library: [libX11.so.6]
0x00000001 (NEEDED) Shared library: [libpixman-1.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
So, there's no runtime lookup of undefined symbols, I just want link my app with "gcc -lcairo -o myapp myapp.c" instead of "gcc -lcairo -lXrender -lX11 ...". On the other hand, static linking myapp would require that I pull in all the libraries to resolve all symbols.
$ pkg-config --libs cairo
-lcairo
$ pkg-config --libs --static cairo
-lcairo -lfreetype -lfontconfig -lexpat -lpng12 -lz -lm -lXrender -lpixman-1 -lX11 -lpthread -lxcb-xlib -lxcb -lXau -lXdmcp
Regardless of how I want to link cairo, I need to be able to find the headers for fontconfig, Xrender and X11 since the datatypes are exposed by cairo.
That's the extremely common case where one library uses another library's datatypes and symbols. It does have something to do with static linking, but it's all part of not acquiring more DT_NEEDED libs then necessary.
http://
As I said before, the case you're describing with gconf and dbus is different and is not handled really well by pkg-config since it expects that you will need to access the dbus headers when compiling. Maybe there should be another pkg-config field like Requires.privatelib that does not expose the CFLAGS.
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #60 |
(In reply to comment #26)
...
> I'm writing a cairo app, so I want to link it to libcairo. However, in order to
> compile my app, it also needs to be get the Xrender headers and link to
> libXrender. Now, I could directly link my app to libXrender, but since I don't
> use any Xrender symbols, it's extra baggage. The linker will still resolve all
> the symbols at build time because libXrender is marked with a a DT_NEEDED tag
> in libcairo.
I Don't use cairo, so forgive me if I say weird things.
If you really do not use libXrender symbol while using cairo, why just not include cairo-xlib-
Now if linking with xrender is only optional when using cairo, then it should be handled in another .pc or if cairo apps aren't expecting to directly links xrender at all, then it should be best to have X11/extensions/
> $ readelf -d /usr/lib/
The internal dependency of cairo itself is not in question.
...
> So, there's no runtime lookup of undefined symbols, I just want link my app
As you have defined your fictional app not to use symbol from xrender, it is necessary true. But doesn't help with some more info either.
> with "gcc -lcairo -o myapp myapp.c" instead of "gcc -lcairo -lXrender -lX11
> ...". On the other hand, static linking myapp would require that I pull in all
> the libraries to resolve all symbols.
What if an application (compiled gcc -lcairo -o myapp myapp.c ) using cairo and xrender symbol is provided on a system where cario have been compiled without xrender and the xrender library isn't available ?
> Regardless of how I want to link cairo, I need to be able to find the headers
> for fontconfig, Xrender and X11 since the datatypes are exposed by cairo.
So why they aren't in Requires: instead of Requires.private ?
OK , there is the Overlink problem , so another workaround would be to have @LIBX11_CFLAGS@ @LIBX11_CFLAGS@ @LIBX11_CFLAGS@ added in cairo.pc.in at the Clags libs.Then the cairo maintainer would have to requires the related -devel package manually.
But in the majority of the cases, Cflags and Libs from Requires.private doesn't matches. When building your application against cario shared/static, you don't need the -I/usr/
This is usually the case since whenever it is possible, internal dependencies should be hidden from the API.
> That's the extremely common case where one library uses another library's
> datatypes and symbols. It does have something to do with static linking, but
> it's all part of not acquiring more DT_NEEDED libs then necessary.
A agree that there is a need to reduce linking whenever it is possible.
> http://
> As I said before, the case you're describing with gconf and dbus is different
> and is not handled really well by pkg-config since it expects that you will
> need to access the dbus headers when compi...
In Red Hat Bugzilla #224148, Dan (dan-redhat-bugs) wrote : | #61 |
If you think pkg-config is not designed correctly, please bring the discussion to the pkg-config list. Or look in the pkg-config archives since there have been many discussions on Requires.private.
http://
The fact of the matter is that fedora can't just change the behavior of the tool because it's inconvenient. Although there is no formal specification, what I've described is the expected and stated behavior of Requires.private. It can't mean one thing on debian and another thing on fedora. That makes the tool useless.
In Red Hat Bugzilla #224148, Mamoru (mamoru-redhat-bugs) wrote : | #62 |
(In reply to comment #28)
> The fact of the matter is that fedora can't just change the behavior of the
> tool because it's inconvenient. Although there is no formal specification, what
> I've described is the expected and stated behavior of Requires.private. It
> can't mean one thing on debian and another thing on fedora. That makes the tool
> useless.
This is not correct. In many applications Fedora already adds
its own implementation.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #63 |
You can continue discussing this here. But if you want to see any behaviour changes, the discussion needs to happen on the pkg-config list upstream.
Fedora is not going to deviate from upstream behaviour for basic development infrastructure.
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #64 |
This seems to be the nearest upstream bug-report.
http://
I'm still searching for historic and previous reports/talks.
I wonder if an acceptable workaround wouldn't be to have pkg-config --cflags foo to remain quiet if there is missing .pc from Requires.private.
The more correct Fix would be to sort out
Requires.Cflags from Requires.private, because the same info is taken from Requires.private, but for different usage.
I understand the Overlinking concern here, But while trying to fix it, the problem has just moved elsewhere. (with Over requiring dependencies somehow).
In Red Hat Bugzilla #224148, Nicolas (nicolas-redhat-bugs) wrote : | #65 |
This bug is re-open (agreed with mclasen) with the aim for the problem to be solved with upstream.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #66 |
Fwiw, I did no such thing (agree to reopen this). I just tired to fight the close/reopen game with you.
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #67 |
How very unfriendly of you to take this to FESCo without even informing me.
Jan Niklas Hasse (jhasse) wrote : | #25 |
Binary package hint: libxxf86vm-dev
When you install libxxf86vm-dev and don't have libxext-dev installed you'll get the following error message when trying to use the .pc file:
jhasse@hardy:~$ pkg-config xxf86vm --cflags --libs
Package xext was not found in the pkg-config search path.
Perhaps you should add the directory containing `xext.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xext', required by 'Xxf86vm', not found
jhasse@hardy:~$
Bryce Harrington (bryce) wrote : | #26 |
Hi jhasse,
Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.
[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]
Changed in libxxf86vm: | |
status: | New → Incomplete |
Jan Niklas Hasse (jhasse) wrote : | #27 |
I don't think these log files are needed, are they?
In Red Hat Bugzilla #224148, Christian (christian-redhat-bugs) wrote : | #68 |
I've just stumbled over the problem during re-compiling the current compiz package (F10).
I've just fixed it for myself by adding libXres-devel as BR to the spec file.
However, I'm not sure whether that's the correct way dealing with the problem.
Is there already an agreement what would be the best way to fix build problems in existing packages?
In Red Hat Bugzilla #224148, Bug (bug-redhat-bugs) wrote : | #69 |
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
http://
Jan Niklas Hasse (jhasse) wrote : | #28 |
This bug isn't fixed yet. Can someone please reopen it?
tags: | added: hardy |
Jan Niklas Hasse (jhasse) wrote : | #29 |
This still hasen't been fixed in karmic. Please reopen.
affects: | libxxf86vm (Ubuntu) → pkg-config (Ubuntu) |
Changed in pkg-config (Ubuntu): | |
status: | Incomplete → Triaged |
importance: | Undecided → Low |
Jan Niklas Hasse (jhasse) wrote : | #30 |
I still think that libxext-dev should be added as a dependency to the libxxf86vm-dev package until pkg-config fixes the issue (which will probably take years).
tags: |
added: karmic removed: needs-lspci-vvnn needs-xorglog |
Changed in pkg-config (Fedora): | |
status: | Unknown → In Progress |
Changed in pkg-config: | |
status: | Unknown → Confirmed |
Changed in pkg-config (Debian): | |
status: | Unknown → Fix Released |
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #70 |
I agree with comment #30 whole-heartedly , and since fedora is shipping upstream setting here and there is an upstream list and bug to track this now, the issue is resolved->upstream (as far as I'm concerned, the original reporter).
In Red Hat Bugzilla #224148, Matthias (matthias-redhat-bugs) wrote : | #71 |
A new pkgconfig release is imminent, which should finally put this issue to rest.
In Red Hat Bugzilla #224148, Rex (rex-redhat-bugs) wrote : | #72 |
amen! :)
Changed in pkg-config (Fedora): | |
status: | In Progress → Fix Released |
Changed in pkg-config: | |
importance: | Unknown → Medium |
Changed in pkg-config: | |
importance: | Medium → Unknown |
Changed in pkg-config: | |
importance: | Unknown → Medium |
In freedesktop.org Bugzilla #4738, Jan Niklas Hasse (jhasse) wrote : | #31 |
Any news on this?
In freedesktop.org Bugzilla #4738, Dbn-lists (dbn-lists) wrote : | #32 |
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.
Changed in pkg-config (Fedora): | |
importance: | Unknown → High |
status: | Fix Released → Won't Fix |
In freedesktop.org Bugzilla #4738, Simon McVittie (smcv) wrote : | #73 |
See also Bug #105572.
In freedesktop.org Bugzilla #4738, Gitlab-migration (gitlab-migration) wrote : | #74 |
-- 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:/
Changed in pkg-config: | |
status: | Confirmed → Unknown |
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.