From David.Evans at cl.cam.ac.uk Thu Feb 5 07:06:02 2009 From: David.Evans at cl.cam.ac.uk (David Evans) Date: Thu, 5 Feb 2009 15:06:02 +0000 Subject: Getting at Libs.private from autoconf Message-ID: <20090205150602.GA4554@cl.cam.ac.uk> Hi, all. Libs.private is nice but there doesn't seem to b a clean way of getting at --libs --shared from autoconf. How about defining foo_STATICLIBS to do this? Something like *** pkg.m4.orig 2009-02-05 13:34:12.000000000 +0000 --- pkg.m4 2009-02-05 14:15:21.000000000 +0000 *************** *** 105,119 **** [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl pkg_failed=no AC_MSG_CHECKING([for $1]) _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) ! m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS ! and $1[]_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.]) if test $pkg_failed = yes; then --- 105,121 ---- [AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl + AC_ARG_VAR([$1][_STATICLIBS], [linker flags for $1 for static linking, overriding pkg-config])dnl pkg_failed=no AC_MSG_CHECKING([for $1]) _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) _PKG_CONFIG([$1][_LIBS], [libs], [$2]) + _PKG_CONFIG([$1][_STATICLIBS], [libs --static], [$2]) ! m4_define([_PKG_TEXT], [Alternatively, you may set the environment variables $1[]_CFLAGS, ! $1[]_LIBS, and $1[]_STATICLIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.]) if test $pkg_failed = yes; then *************** *** 151,156 **** --- 153,159 ---- else $1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS $1[]_LIBS=$pkg_cv_[]$1[]_LIBS + $1[]_STATICLIBS=$pkg_cv_[]$1[]_STATICLIBS AC_MSG_RESULT([yes]) ifelse([$3], , :, [$3]) fi[]dnl Tested on version 0.22. -- David Evans David.Evans at cl.cam.ac.uk Research Associate http://www.cl.cam.ac.uk/~de239 Computer Laboratory, University of Cambridge From dbn.lists at gmail.com Mon Feb 9 22:42:58 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Mon, 9 Feb 2009 22:42:58 -0800 Subject: [PATCH] Guide to pkg-config Message-ID: <20090210064258.GA3842@conor> I took a stab at writing a guide to pkg-config both for developers and users. It's sort of a braindump, and I can't decide if it's too detailed or not detailed enough. I'm posting it here, though, for comments. You can read it online here: http://people.freedesktop.org/~dbn/pkg-config-guide.html The FAQs come from Matthias'. I'd be happy to fix up any errors or edits people see necessary. Some of the content duplicates pkg-config(1). I didn't see how to avoid that, though. If there's interest, I could convert to DocBook, but I think this is a starting point. Patch is inline below. -- Dan === modified file 'Makefile.am' --- old/Makefile.am 2007-12-29 13:40:41 +0000 +++ new/Makefile.am 2009-02-10 06:20:26 +0000 @@ -11,6 +11,8 @@ m4dir = $(datadir)/aclocal m4_DATA = pkg.m4 +dist_doc_DATA = guide.html + man_MANS = pkg-config.1 EXTRA_DIST = $(m4_DATA) $(man_MANS) README.win32 === added file 'guide.html' --- old/guide.html 1970-01-01 00:00:00 +0000 +++ new/guide.html 2009-02-10 06:18:17 +0000 @@ -0,0 +1,417 @@ + + + + + + + + + + Guide to pkg-config + + + +

Guide to pkg-config

+ +

Dan Nicholson

+ + + +

Overview

+ +

This document aims to give an overview to using the pkg-config + tool from the perspective of both a user and a developer. It reviews the + concepts behind pkg-config, how to write pkg-config files + to support your project, and how to use pkg-config to integrate + with 3rd party projects.

+ +

More information on pkg-config can be found at the + website and in the + pkg-config(1) manual page.

+ +

This document assumes usage of pkg-config on a Unix-like + operating system such as Linux. Some of the details may be different on + other platforms.

+ +

Why?

+ +

Modern computer systems use many layered components to provide + applications to the user. One of the difficulties in assembling these parts + is properly integrating them. pkg-config collects metadata about + the installed libraries on the system and easily provides it to the user. +

+ +

Without a metadata system such as pkg-config, it can be very + difficult to locate and obtain details about the services provided on a + given computer. For a developer, installing pkg-config files with + your package greatly eases adoption of your API.

+ +

Concepts

+ +

The primary use of pkg-config is to provide the necessary + details for compiling and linking a program to a library. This metadata is + stored in pkg-config files. These files have the suffix + .pc and reside in specific locations known to the + pkg-config tool. This will be described in more detail later.

+ +

The file format contains predefined metadata keywords and freeform + variables. An example may be illustrative:

+ +

prefix=/usr/local
+exec_prefix=${prefix}
+includedir=${prefix}/include
+libdir=${exec_prefix}/lib
+
+Name: foo
+Description: The foo library
+Version: 1.0.0
+Cflags: -I${includedir}/foo
+Libs: -L${libdir} -lfoo
+ +

The keyword definitions such as Name: begin with a keyword + followed by a colon and the value. The variables such as prefix= + are a string and value separated by an equals sign. The keywords are defined + and exported by pkg-config. The variables are not necessary, but + can be used by the keyword definitions for flexibility or to store data not + covered by pkg-config.

+ +

Here is a short description of the keyword fields. A more in depth + description of these fields and how to use them effectively will be given in + the Writing pkg-config files section.

+ + + +

Writing pkg-config files

+ +

When creating pkg-config files for a package, it is first + necessary to decide how they will be distributed. Each file is best used to + describe a single library, so each package should have at least as many + pkg-config files as they do installed libraries.

+ +

The package name is determined through the filename of the + pkg-config metadata file. This is the portion of the filename prior + to the .pc suffix. A common choice is to match the library name to + the .pc name. For instance, a package installing libfoo.so + would have a corresponding libfoo.pc file containing the + pkg-config metadata. This choice is not necessary; the .pc + file should simply be a unique identifier for your library. Following the + above example, foo.pc or foolib.pc would probably work + just as well.

+ +

The Name, Description and URL fields are + purely informational and should be easy to fill in. The Version + field is a bit trickier to ensure that it is usable by consumers of the + data. pkg-config uses the algorithm from + RPM for version comparisons. This works best + with a dotted decimal number such as 1.2.3 since letters can cause + unexpected results. The number should be monotonically increasing and be + as specific as possible in describing the library. Usually it's sufficient + to use the package's version number here since it's easy for consumers to + track.

+ +

Before describing the more useful fields, it will be helpful to + demonstrate variable definitions. The most common usage is to define the + installation paths so that they don't clutter the metadata fields. Since + the variables are expanded recursively, this is very helpful when used in + conjunction with autoconf derived paths.

+ +
prefix=/usr/local
+includedir=${prefix}/include
+
+Cflags: -I${includedir}/foo
+ +

The most important pkg-config metadata fields are + Requires, Requires.private, Cflags, Libs + and Libs.private. They will define the metadata used by external + projects to compile and link with the library.

+ +

Requires and Requires.private define other modules + needed by the library. It is usually preferred to use the private variant of + Requires to avoid exposing unnecessary libraries to the program + that is linking with your library. If the program will not be using the + symbols of the required library, it should not be linking directly to that + library. See the discussion of + overlinking for a more + thorough explanation.

+ +

Since pkg-config always exposes the link flags of the + Requires libraries, these modules will become direct dependencies + of the program. On the other hand, libraries from Requires.private + will only be included when static linking. For this reason, it is usually + only appropriate to add modules from the same package in Requires. +

+ +

The Libs field contains the link flags necessary to use that + library. In addition, Libs and Libs.private contain link + flags for other libraries not supported by pkg-config. Similar to + the Requires field, it is preferred to add link flags for external + libraries to the Libs.private field so programs do not acquire an + additional direct dependency.

+ +

Finally, the Cflags contains the compiler flags for using the + library. Unlike the Libs field, there is not a private variant of + Cflags. This is because the data types and macro definitions are + needed regardless of the linking scenario.

+ +

Using pkg-config files

+ +

Assuming that there are .pc files installed on the system, the + pkg-config tool is used to extract the metadata for usage. A short + description of the options can be seen by executing + pkg-config --help. A more in depth discussion can be found in the + pkg-config(1) manual page. This section will provide a brief + explanation of common usages. + +

Consider a system with two modules, foo and bar. + Their .pc files might look like this:

+ +
foo.pc:
+prefix=/usr
+exec_prefix=${prefix}
+includedir=${prefix}/include
+libdir=${exec_prefix}/lib
+
+Name: foo
+Description: The foo library
+Version: 1.0.0
+Cflags: -I${includedir}/foo
+Libs: -L${libdir} -lfoo
+
+bar.pc:
+prefix=/usr
+exec_prefix=${prefix}
+includedir=${prefix}/include
+libdir=${exec_prefix}/lib
+
+Name: bar
+Description: The bar library
+Version: 2.1.2
+Requires.private: foo >= 0.7
+Cflags: -I${includedir}
+Libs: -L${libdir} -lbar
+ +

The version of the modules can be obtained with the --modversion + option.

+ +
$ pkg-config --modversion foo
+1.0.0
+$ pkg-config --modversion bar
+2.1.2
+ +

To print the link flags needed for each module, use the --libs + option.

+ +
$ pkg-config --libs foo
+-lfoo
+$ pkg-config --libs bar
+-lbar
+ +

Notice that pkg-config has suppressed part of the Libs + field for both modules. This is because it treats the -L flag + specially and knows that the ${libdir} directory /usr/lib + is part of the system linker search path. This keeps pkg-config + from interfering with the linker operation.

+ +

Also, although foo is required by bar, the link flags + for foo are not output. This is because foo is not + directly needed by an application that only wants to use the bar + library. For statically linking a bar application, we need both + sets of linker flags:

+ +
$ pkg-config --libs --static bar
+-lbar -lfoo
+ +

pkg-config needs to output both sets of link flags in this case + to ensure that the statically linked application will find all the necessary + symbols. On the other hand, it will always output all the Cflags. +

+ +
$ pkg-config --cflags bar
+-I/usr/include/foo  
+$ pkg-config --cflags --static bar
+-I/usr/include/foo
+ +

Another useful option, --exists, can be used to test for a + module's availability.

+ +
$ pkg-config --exists foo
+$ echo $?
+0
+ +

One of the nicest features of pkg-config is providing version + checking. It can be used to determine if a sufficient version is available. +

+ +
$ pkg-config --libs "bar >= 2.7"
+Requested 'bar >= 2.7' but version of bar is 2.1.2
+ +

Some commands will provide more verbose output when combined with the + --print-errors option.

+ +
$ pkg-config --exists --print-errors xoxo
+Package xoxo was not found in the pkg-config search path.
+Perhaps you should add the directory containing `xoxo.pc'
+to the PKG_CONFIG_PATH environment variable
+No package 'xoxo' found
+ +

The message above references the PKG_CONFIG_PATH environment + variable. This variable is used to augment pkg-config's search + path. On a typical Unix system, it will search in the directories + /usr/lib/pkgconfig and /usr/share/pkgconfig. This will + usually cover system installed modules. However, some local modules may be + installed in a different prefix such as /usr/local. In that case, + it's necessary to prepend the search path so that pkg-config can + locate the .pc files.

+ +
$ pkg-config --modversion hello
+Package hello was not found in the pkg-config search path.
+Perhaps you should add the directory containing `hello.pc'
+to the PKG_CONFIG_PATH environment variable
+No package 'hello' found
+$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
+$ pkg-config --modversion hello
+1.0.0
+ +

A few autoconf macros + are also provided to ease integration of pkg-config modules into + projects.

+ + + + +

Frequently asked questions

+ +
    +
  1. My program uses library x. What do I do?
    2. + +

    The pkg-config output can easily be used on the compiler + command line. Assuming the x library has a x.pc + pkg-config file:

    + +
    cc `pkg-config --cflags --libs x` -o myapp myapp.c
    + +

    The integration can be more robust when used with + autoconf and + automake. By using the + supplied PKG_CHECK_MODULES macro, the metadata is easily accessed + in the build process.

    + +
    configure.ac:
+PKG_CHECK_MODULES([X], [x])
+
+Makefile.am:
+myapp_CFLAGS = $(X_CFLAGS)
+myapp_LDADD = $(X_LIBS)
    + +

    If the x module is found, the macro will fill and substitute + the X_CFLAGS and X_LIBS variables. If the module is not + found, an error will be produced. Optional 3rd and 4th arguments can be + supplied to PKG_CHECK_MODULES to control actions when the module + is found or not.

    + +
  2. My library z installs header files which include libx + headers. What do I put in my z.pc file?
    3. + +

    If the x library has pkg-config support, add it to + the Requires.private field. If it does not, augment the + Cflags field with the necessary compiler flags for using the + libx headers. In either case, pkg-config will output + the compiler flags when --static is used or not.

    + +
  3. My library z uses libx internally, but does not + expose libx data types in its public API. What do I put in my + z.pc file?
    4. + +

    Again, add the module to Requires.private if it supports + pkg-config. In this case, the compiler flags will be emitted + unnecessarily, but it ensures that the linker flags will be present when + linking statically. If libx does not support pkg-config, + add the necessary linker flags to Libs.private.

    +
+ +
+ +
Dan Nicholson <dbn.lists (at) gmail (dot) com>
+ +

Copyright (c) 2009 Dan Nicholson.
+ This document is licensed under the + GNU Free Documentation License, Version 1.3 + or any later version.

+ + + From dbn.lists at gmail.com Tue Feb 10 06:46:28 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 10 Feb 2009 06:46:28 -0800 Subject: [PATCH] Guide to pkg-config In-Reply-To: <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> Message-ID: <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> On Tue, Feb 10, 2009 at 2:39 AM, Mat?j T?? wrote: > Hi Dan, > That's very nice and IMHO needed and I would like to contribute to > that guide as well... > What about rewriting it to texinfo, the standard GNU documentation system? > http://en.wikipedia.org/wiki/Texinfo Well, there's a couple things that are negatives for texinfo (for me personally). 1. I've never written texinfo. 2. I hate the info viewer. However, if someone converted it to texinfo, I'm sure I could pick up the concepts. And as long as the HTML output was shipped I'd be happy. On the other hand, I have quite a bit of experience with DocBook XML, so that is where I'd lean if I intended to move to a more powerful documentation system. It's not that big a deal to me, though. P.S. Added the list back. -- Dan From matej.tyc at gmail.com Tue Feb 10 10:08:48 2009 From: matej.tyc at gmail.com (=?UTF-8?Q?Mat=C4=9Bj_T=C3=BD=C4=8D?=) Date: Tue, 10 Feb 2009 19:08:48 +0100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> Message-ID: <1234289328.2890.3.camel@matej-desktop> Hello Dan, > 1. I've never written texinfo. Everybody can figure things out quite quickly, that's not a big problem if you don't want it to become one. > > 2. I hate the info viewer. Don't worry, me too :-) > > However, if someone converted it to texinfo, I'm sure I could pick up > the concepts. And as long as the HTML output was shipped I'd be happy. I can do that with no problems. What about putting this to some SVN repository? There is an easy way to produce HTML, PDF and Docbook from Texinfo, this does not sound bad, does it? Matej From mle+tools at mega-nerd.com Tue Feb 10 13:27:04 2009 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 11 Feb 2009 08:27:04 +1100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <20090210064258.GA3842@conor> References: <20090210064258.GA3842@conor> Message-ID: <20090211082704.13951061.mle+tools@mega-nerd.com> Dan Nicholson wrote: > I took a stab at writing a guide to pkg-config both for developers and > users. It's sort of a braindump, and I can't decide if it's too detailed > or not detailed enough. I'm posting it here, though, for comments. You > can read it online here: > > http://people.freedesktop.org/~dbn/pkg-config-guide.html Looks good, but doesn't cover the cross-compiling case. Would you be interested in adding that? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "There may be fairies at the bottom of the garden. There is no evidence for it, but you can't prove that there aren't any, so shouldn't we be agnostic with respect to fairies?" -- Richard Dawkins From mle+tools at mega-nerd.com Tue Feb 10 13:26:09 2009 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 11 Feb 2009 08:26:09 +1100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <1234289328.2890.3.camel@matej-desktop> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> <1234289328.2890.3.camel@matej-desktop> Message-ID: <20090211082609.f9efc36b.mle+tools@mega-nerd.com> Mat?j T?? wrote: > Hello Dan, > > 1. I've never written texinfo. > Everybody can figure things out quite quickly, that's not a big problem > if you don't want it to become one. > > > > 2. I hate the info viewer. > Don't worry, me too :-) pinfo is a very good replacement for info. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures." -- Alan Perlis From dbn.lists at gmail.com Tue Feb 10 13:53:36 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 10 Feb 2009 13:53:36 -0800 Subject: [PATCH] Guide to pkg-config In-Reply-To: <20090211082704.13951061.mle+tools@mega-nerd.com> References: <20090210064258.GA3842@conor> <20090211082704.13951061.mle+tools@mega-nerd.com> Message-ID: <91705d080902101353h4d5619d7h29935f26a2cb20e9@mail.gmail.com> On Tue, Feb 10, 2009 at 1:27 PM, Erik de Castro Lopo wrote: > Dan Nicholson wrote: > >> I took a stab at writing a guide to pkg-config both for developers and >> users. It's sort of a braindump, and I can't decide if it's too detailed >> or not detailed enough. I'm posting it here, though, for comments. You >> can read it online here: >> >> http://people.freedesktop.org/~dbn/pkg-config-guide.html > > Looks good, but doesn't cover the cross-compiling case. Would you > be interested in adding that? I don't mind, but I hope it wouldn't become a significant part of the document. Cross-compiling is a pretty niche area for the random person being confronted with pkg-config. Also, I've never actually tried to use pkg-config in a cross-compiling scenario, so I'm probably not qualified to write that part. -- Dan From mle+tools at mega-nerd.com Tue Feb 10 14:07:55 2009 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 11 Feb 2009 09:07:55 +1100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <91705d080902101353h4d5619d7h29935f26a2cb20e9@mail.gmail.com> References: <20090210064258.GA3842@conor> <20090211082704.13951061.mle+tools@mega-nerd.com> <91705d080902101353h4d5619d7h29935f26a2cb20e9@mail.gmail.com> Message-ID: <20090211090755.5d574b72.mle+tools@mega-nerd.com> Dan Nicholson wrote: > I don't mind, but I hope it wouldn't become a significant part of the > document. Cross-compiling is a pretty niche area for the random person > being confronted with pkg-config. I think its actually becoming more and more common. For instance I have a project where I advise all people wanting windows binaries to cross compile them from linux. > Also, I've never actually tried to > use pkg-config in a cross-compiling scenario, so I'm probably not > qualified to write that part. I've blogged about it a bit: http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/pkg-config.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/cross_compiling.html http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/cross_compiling_2.html Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Attacks by Microsoft Chairman Bill Gates on the GNU General Public License, under which much open source and free software is distributed, have been driven by a fear that the GPL creates a domain of software that Microsoft cannot privatize and control" -- Richard Stallman From matej.tyc at gmail.com Tue Feb 10 14:47:10 2009 From: matej.tyc at gmail.com (=?UTF-8?Q?Mat=C4=9Bj_T=C3=BD=C4=8D?=) Date: Tue, 10 Feb 2009 23:47:10 +0100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <20090211090755.5d574b72.mle+tools@mega-nerd.com> References: <20090210064258.GA3842@conor> <20090211082704.13951061.mle+tools@mega-nerd.com> <91705d080902101353h4d5619d7h29935f26a2cb20e9@mail.gmail.com> <20090211090755.5d574b72.mle+tools@mega-nerd.com> Message-ID: <1234306030.2890.29.camel@matej-desktop> On Wed, 2009-02-11 at 09:07 +1100, Erik de Castro Lopo wrote: > Dan Nicholson wrote: > > > I don't mind, but I hope it wouldn't become a significant part of the > > document. Cross-compiling is a pretty niche area for the random person > > being confronted with pkg-config. > > I think its actually becoming more and more common. For instance > I have a project where I advise all people wanting windows binaries > to cross compile them from linux. I agree with that. pkg-config is quite easy to use, but it currently breaks cross-compilation out of the box. Since the howto doesn't have to consist of only one chapter, the text shouldn't become too difficult because of this, I think :-) Matej From dbn.lists at gmail.com Tue Feb 10 14:58:39 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Tue, 10 Feb 2009 14:58:39 -0800 Subject: [PATCH] Guide to pkg-config In-Reply-To: <1234289328.2890.3.camel@matej-desktop> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> <1234289328.2890.3.camel@matej-desktop> Message-ID: <91705d080902101458s26adacb9m821df53a497d37d0@mail.gmail.com> On Tue, Feb 10, 2009 at 10:08 AM, Mat?j T?? wrote: >> >> However, if someone converted it to texinfo, I'm sure I could pick up >> the concepts. And as long as the HTML output was shipped I'd be happy. > I can do that with no problems. What about putting this to some SVN > repository? Well, I posted it here with the hopes that it would be applied to the bzr repo. If that's not possible I could version control it, but it would be in git, so I hope that's not a problem. :) > There is an easy way to produce HTML, PDF and Docbook from Texinfo, this > does not sound bad, does it? Yeah, I just meant that I would only support the move if the HTML output was in the tarball. I have very little interest in pkg-config.info. So, if you'd like to convert it to texinfo, go for it. However, I would hope to hear from Tollef before making any major changes. My principle desire would be to have this shipped with pkg-config rather than living out in the wild. -- Dan From tfheen at err.no Tue Feb 10 22:33:14 2009 From: tfheen at err.no (Tollef Fog Heen) Date: Wed, 11 Feb 2009 07:33:14 +0100 Subject: Getting at Libs.private from autoconf In-Reply-To: <20090205150602.GA4554@cl.cam.ac.uk> (David Evans's message of "Thu, 5 Feb 2009 15:06:02 +0000") References: <20090205150602.GA4554@cl.cam.ac.uk> Message-ID: <87fxilbhzp.fsf@xoog.err.no> ]] David Evans | Libs.private is nice but there doesn't seem to b a clean way of | getting at --libs --shared from autoconf. How about defining | foo_STATICLIBS to do this? Something like The problem with this (and particularly this approach) is that you end up always calling pkg-config --static on all invocations. This is something we don't want to: in the general case, you don't need all recursive private dependencies of your requirements. I guess we could add a fifth parameter to PKG_CHECK_MODULES, or add an PKG_CHECK_MODULES_STATIC. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are From David.Evans at cl.cam.ac.uk Wed Feb 11 01:39:27 2009 From: David.Evans at cl.cam.ac.uk (David Evans) Date: Wed, 11 Feb 2009 09:39:27 +0000 Subject: Getting at Libs.private from autoconf In-Reply-To: <87fxilbhzp.fsf@xoog.err.no> References: <20090205150602.GA4554@cl.cam.ac.uk> <87fxilbhzp.fsf@xoog.err.no> Message-ID: <20090211093927.GB11428@cl.cam.ac.uk> On Wed, Feb 11, 2009 at 07:33:14AM +0100, Tollef Fog Heen wrote: > ]] David Evans > > | Libs.private is nice but there doesn't seem to b a clean way of > | getting at --libs --shared from autoconf. How about defining > | foo_STATICLIBS to do this? Something like > > The problem with this (and particularly this approach) is that you end > up always calling pkg-config --static on all invocations. True,. although you already call pkg-config twice (for --cflags and --libs). Is --statiuc expeced to be expensive or is it just that it's silly to call it evvery time if it's rarely used? > This is > something we don't want to: in the general case, you don't need all > recursive private dependencies of your requirements. I guess we could > add a fifth parameter to PKG_CHECK_MODULES, or add an > PKG_CHECK_MODULES_STATIC. > Well, something less ugly than AC_SUBST([SWI_STATICLIBS], [`pkg-config --libs --static pl`]) would be nice. -- David Evans David.Evans at cl.cam.ac.uk Research Associate http://www.cl.cam.ac.uk/~de239 Computer Laboratory, University of Cambridge From tfheen at err.no Wed Feb 11 13:20:39 2009 From: tfheen at err.no (Tollef Fog Heen) Date: Wed, 11 Feb 2009 22:20:39 +0100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <91705d080902101458s26adacb9m821df53a497d37d0@mail.gmail.com> (Dan Nicholson's message of "Tue, 10 Feb 2009 14:58:39 -0800") References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> <1234289328.2890.3.camel@matej-desktop> <91705d080902101458s26adacb9m821df53a497d37d0@mail.gmail.com> Message-ID: <87r624acwo.fsf@xoog.err.no> ]] Dan Nicholson | On Tue, Feb 10, 2009 at 10:08 AM, Mat?j T?? wrote: | >> | >> However, if someone converted it to texinfo, I'm sure I could pick up | >> the concepts. And as long as the HTML output was shipped I'd be happy. | > I can do that with no problems. What about putting this to some SVN | > repository? | | Well, I posted it here with the hopes that it would be applied to the | bzr repo. If that's not possible I could version control it, but it | would be in git, so I hope that's not a problem. :) Wow, thanks a lot for this. It's quite a good introduction. :-) I'd be happy to have it in the bzr repo. However, since we're already nitpicking, would you mind licencing it under the GPL (possibly dual-licence if you strongly prefer the GFDL)? This is so we can cut and paste between the docs and pkg-config itself. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are From tfheen at err.no Wed Feb 11 13:21:39 2009 From: tfheen at err.no (Tollef Fog Heen) Date: Wed, 11 Feb 2009 22:21:39 +0100 Subject: Getting at Libs.private from autoconf In-Reply-To: <20090211093927.GB11428@cl.cam.ac.uk> (David Evans's message of "Wed, 11 Feb 2009 09:39:27 +0000") References: <20090205150602.GA4554@cl.cam.ac.uk> <87fxilbhzp.fsf@xoog.err.no> <20090211093927.GB11428@cl.cam.ac.uk> Message-ID: <87mycsacv0.fsf@xoog.err.no> ]] David Evans | On Wed, Feb 11, 2009 at 07:33:14AM +0100, Tollef Fog Heen wrote: | > ]] David Evans | > | > | Libs.private is nice but there doesn't seem to b a clean way of | > | getting at --libs --shared from autoconf. How about defining | > | foo_STATICLIBS to do this? Something like | > | > The problem with this (and particularly this approach) is that you end | > up always calling pkg-config --static on all invocations. | | True,. although you already call pkg-config twice (for --cflags and | --libs). Is --statiuc expeced to be expensive or is it just that it's | silly to call it evvery time if it's rarely used? The problem is it'll break if you don't have all the recursive dependencies installed, not the cost of calling pkg-config. | > This is | > something we don't want to: in the general case, you don't need all | > recursive private dependencies of your requirements. I guess we could | > add a fifth parameter to PKG_CHECK_MODULES, or add an | > PKG_CHECK_MODULES_STATIC. | | Well, something less ugly than | | AC_SUBST([SWI_STATICLIBS], [`pkg-config --libs --static pl`]) | | would be nice. Indeed. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are From dbn.lists at gmail.com Wed Feb 11 13:26:52 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Wed, 11 Feb 2009 13:26:52 -0800 Subject: [PATCH] Guide to pkg-config In-Reply-To: <87r624acwo.fsf@xoog.err.no> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> <1234289328.2890.3.camel@matej-desktop> <91705d080902101458s26adacb9m821df53a497d37d0@mail.gmail.com> <87r624acwo.fsf@xoog.err.no> Message-ID: <91705d080902111326h7af254ccmf71073cbb71607ee@mail.gmail.com> On Wed, Feb 11, 2009 at 1:20 PM, Tollef Fog Heen wrote: > ]] Dan Nicholson > > | On Tue, Feb 10, 2009 at 10:08 AM, Mat?j T?? wrote: > | >> > | >> However, if someone converted it to texinfo, I'm sure I could pick up > | >> the concepts. And as long as the HTML output was shipped I'd be happy. > | > I can do that with no problems. What about putting this to some SVN > | > repository? > | > | Well, I posted it here with the hopes that it would be applied to the > | bzr repo. If that's not possible I could version control it, but it > | would be in git, so I hope that's not a problem. :) > > Wow, thanks a lot for this. It's quite a good introduction. :-) I'd be > happy to have it in the bzr repo. > > However, since we're already nitpicking, would you mind licencing it > under the GPL (possibly dual-licence if you strongly prefer the GFDL)? > This is so we can cut and paste between the docs and pkg-config itself. Ah, right, I meant to mention this in my first mail. I have no attachment to the GFDL, it just seemed like a reasonable license for documentation. But I'm not opposed to GPLv2 or GPLv2+ or anything else that would make maintenance easier. I wasn't even going to license it at first, but decided it would probably be best to have something. :) Let me know what license you'd like to see, and I'll resubmit the patch. -- Dan From David.Evans at cl.cam.ac.uk Thu Feb 12 03:20:48 2009 From: David.Evans at cl.cam.ac.uk (David Evans) Date: Thu, 12 Feb 2009 11:20:48 +0000 Subject: Getting at Libs.private from autoconf In-Reply-To: <87mycsacv0.fsf@xoog.err.no> References: <20090205150602.GA4554@cl.cam.ac.uk> <87fxilbhzp.fsf@xoog.err.no> <20090211093927.GB11428@cl.cam.ac.uk> <87mycsacv0.fsf@xoog.err.no> Message-ID: <20090212112048.GA7817@cl.cam.ac.uk> On Wed, Feb 11, 2009 at 10:21:39PM +0100, Tollef Fog Heen wrote: > ]] David Evans > > | True,. although you already call pkg-config twice (for --cflags and > | --libs). Is --statiuc expeced to be expensive or is it just that it's > | silly to call it evvery time if it's rarely used? > > The problem is it'll break if you don't have all the recursive > dependencies installed, not the cost of calling pkg-config. > Ahahh! Fair enough, though if you're doing static linking and you don't have the dependencies installed, you're in for pain anyway, Still, there might be a nasty interaction with cross compiling. -- David Evans David.Evans at cl.cam.ac.uk Research Associate http://www.cl.cam.ac.uk/~de239 Computer Laboratory, University of Cambridge From tfheen at err.no Thu Feb 12 04:26:34 2009 From: tfheen at err.no (Tollef Fog Heen) Date: Thu, 12 Feb 2009 13:26:34 +0100 Subject: Getting at Libs.private from autoconf In-Reply-To: <20090212112048.GA7817@cl.cam.ac.uk> (David Evans's message of "Thu, 12 Feb 2009 11:20:48 +0000") References: <20090205150602.GA4554@cl.cam.ac.uk> <87fxilbhzp.fsf@xoog.err.no> <20090211093927.GB11428@cl.cam.ac.uk> <87mycsacv0.fsf@xoog.err.no> <20090212112048.GA7817@cl.cam.ac.uk> Message-ID: <87wsbvj0xx.fsf@qurzaw.linpro.no> ]] David Evans | On Wed, Feb 11, 2009 at 10:21:39PM +0100, Tollef Fog Heen wrote: | > ]] David Evans | > | > | True,. although you already call pkg-config twice (for --cflags and | > | --libs). Is --statiuc expeced to be expensive or is it just that it's | > | silly to call it evvery time if it's rarely used? | > | > The problem is it'll break if you don't have all the recursive | > dependencies installed, not the cost of calling pkg-config. | | Ahahh! Fair enough, though if you're doing static linking and | you don't have the dependencies installed, you're in for pain anyway, | Still, there might be a nasty interaction with cross compiling. Of course, which is why I wanted this to be added as an option (for the writer of the configure.ac file) rather than it always being called. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From matej.tyc at gmail.com Thu Feb 12 11:53:20 2009 From: matej.tyc at gmail.com (=?UTF-8?Q?Mat=C4=9Bj_T=C3=BD=C4=8D?=) Date: Thu, 12 Feb 2009 20:53:20 +0100 Subject: [PATCH] Guide to pkg-config In-Reply-To: <91705d080902111326h7af254ccmf71073cbb71607ee@mail.gmail.com> References: <20090210064258.GA3842@conor> <670992c60902100239t407ac0fbhfd8eac5e870fff3d@mail.gmail.com> <91705d080902100646r59432b89jb4159386cc27ce3a@mail.gmail.com> <1234289328.2890.3.camel@matej-desktop> <91705d080902101458s26adacb9m821df53a497d37d0@mail.gmail.com> <87r624acwo.fsf@xoog.err.no> <91705d080902111326h7af254ccmf71073cbb71607ee@mail.gmail.com> Message-ID: <1234468400.2906.4.camel@matej-desktop> I attach the texinfo file. It should be +- the same as the HTML. You can generate HTML using 'makeinfo --html'. You can also generate PDF using 'texi2pdf' program. Can you place it to some repo? I can, if there is no other option... Regards, Matej -------------- next part -------------- A non-text attachment was scrubbed... Name: pkg-config.texi Type: text/x-texinfo Size: 15132 bytes Desc: not available Url : http://lists.freedesktop.org/archives/pkg-config/attachments/20090212/918a6a13/attachment-0001.bin From aecostas at gmail.com Wed Feb 25 08:26:39 2009 From: aecostas at gmail.com (=?ISO-8859-1?Q?Andr=E9s_Est=E9vez_Costas?=) Date: Wed, 25 Feb 2009 17:26:39 +0100 Subject: Dependencies Message-ID: <901a4c140902250826w71318639rc415e088a1e01d53@mail.gmail.com> Hi all, I wanted to know if is there any way to include a library in a .pc file if only some condition is satisfied? B.R -- Andr?s Est?vez Costas http://ultimastecnoloxias.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/pkg-config/attachments/20090225/2ba02714/attachment.htm From tfheen at err.no Wed Feb 25 11:09:14 2009 From: tfheen at err.no (Tollef Fog Heen) Date: Wed, 25 Feb 2009 20:09:14 +0100 Subject: Dependencies In-Reply-To: <901a4c140902250826w71318639rc415e088a1e01d53@mail.gmail.com> (=?utf-8?Q?=22Andr=C3=A9s_Est=C3=A9vez?= Costas"'s message of "Wed, 25 Feb 2009 17:26:39 +0100") References: <901a4c140902250826w71318639rc415e088a1e01d53@mail.gmail.com> Message-ID: <87ab8a9vvp.fsf@xoog.err.no> ]] Andr?s Est?vez Costas | I wanted to know if is there any way to include a library in a .pc file if | only some condition is satisfied? There isn't. You can generate the .pc file build-time, though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are From kwizart at gmail.com Fri Feb 27 08:18:46 2009 From: kwizart at gmail.com (Nicolas Chauvet) Date: Fri, 27 Feb 2009 17:18:46 +0100 Subject: Requires.private behaviour and usage. Message-ID: Hello! As reported in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=224148 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: http://lists.freedesktop.org/archives/pkg-config/2007-January/000180.html But was incorrectly associated with this bug: http://bugs.freedesktop.org/show_bug.cgi?id=4738 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 : https://bugzilla.redhat.com/show_bug.cgi?id=224148#c24 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. http://bugs.freedesktop.org/attachment.cgi?id=15030 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 change). What do you think ? Nicolas (kwizart) From dbn.lists at gmail.com Fri Feb 27 09:32:15 2009 From: dbn.lists at gmail.com (Dan Nicholson) Date: Fri, 27 Feb 2009 09:32:15 -0800 Subject: Requires.private behaviour and usage. In-Reply-To: References: Message-ID: <91705d080902270932y6a731ddey2ff0b1304a150c9e@mail.gmail.com> On Fri, Feb 27, 2009 at 8:18 AM, Nicolas Chauvet wrote: > > 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 > change). I don't think the Requires.private behavior can be changed. That's will just break a lot of things and cause chaos. Requires and Requires.private mean that you want the Cflags and Libs* from dependent packages. Period. However, I think it would be good to reflect that you need to require a package, but only for specific parts. So, I think three new fields would be good (for completeness): Requires.cflags - Cflags from listed packages and their Requires/Requires.private/Requires.cflags packages Requires.libs - Libs/Libs.private from listed packages and their Requires/Requires.private/Requires.libs/Requires.libs.private packages Requires.libs.private - Libs.private from listed packages and their Requires.private/Requires.libs.private packages This would be analogous to Cflags, Libs and Libs.private, but the information is collected via the Requires mechanism. The two obvious reasons why you would want this is if you are using another package's datatypes or symbols, but not both. I haven't looked at exactly how this would be implemented, but I think it could be made to work if I recall the handling of the fields from the last time I looked at that part of the code. -- Dan From amitharlikar at gmail.com Sat Feb 28 03:10:16 2009 From: amitharlikar at gmail.com (amit harlikar) Date: Sat, 28 Feb 2009 15:40:16 +0430 Subject: gtk error Message-ID: <95a16d4e0902280310i3339524fp4158a62034ea9b4a@mail.gmail.com> i was trying to do program that will display GtkWidget window, program was get compiled sucessfully but when i am trying to run the program it will show me followin error what should i do. Xlib: connection to "0:0.0" refused by server Xlib: No protocol specified (gtk1:8237): Gtk-WARNING **: cannot open display -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/pkg-config/attachments/20090228/bbaea9fe/attachment.htm