# pkgconf: a package compiler and linker metadata toolkit, not a pkg-config clone

> pkgconf reads .pc files and reports the compiler and linker flags a development library needs, but it is a reimplementation rather than a drop-in replacement, with a flattened dependency graph, virtual packages, Conflicts support, a shared library for other tooling, and SBOM generators. The upstream project says plainly that it does not aim for bug-level compatibility with the freedesktop original.

**pkgconf/pkgconf** — package compiler and linker metadata toolkit

- Repository: https://github.com/pkgconf/pkgconf
- Stars: 663 · Forks: 146
- Language: C
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pkgconf-pkgconf

## A metadata reader, and an honest statement that it is not pkg-config

pkgconf is a program that helps to configure compiler and linker flags for development libraries. The README is precise about its relationship to the original: it is a superset of the functionality provided by pkg-config from freedesktop.org, but it does not provide bug-compatibility with the original pkg-config. The bug compatibility section repeats the point in practical terms. If you feel there is a legitimate regression against pkg-config, you are asked to report it, but also to make sure the .pc files are valid and follow the rules of the pkg-config tutorial, since fixing them to follow the specified rules will most likely solve the problem. That is the right way to think about adopting it. You are not swapping a binary for a drop-in, you are adopting a resolver that answers the same questions with a different internal model, and the metadata files become the contract.

## A flattened dependency graph, and why that changes link lines

The technical reason pkgconf exists is described under why pkgconf over the original pkg-config. It builds a flattened directed dependency graph, which gives more insight into the relationships between dependencies, allows some link-time dependency optimization, allows the user to link their binaries more conservatively, and that may be helpful in some environments such as when prelink(1) is used. The second difference is scale. The solver is optimized to handle large dependency graphs with hundreds of thousands of edges, with any project using the Abseil frameworks given as an example. The remaining differences are semantic rather than performance. pkgconf has full support for virtual packages while the original pkg-config does not, and it fully supports Conflicts at dependency resolution time, which is more efficient than checking for Conflicts while walking the dependency graph. For a distribution assembling a large dependency set, those three properties are the case for the tool.

## Avoiding overlinking depends on honest .pc files

The linker flag optimisation is conditional, and the README says so. It depends on the pkg-config module properly declaring its dependency tree instead of using Libs and Cflags fields to directly link against other modules that have their own pkg-config metadata installed. The practice of describing unrelated dependencies through Libs and Cflags is not recommended in Dan Nicholson's pkg-config tutorial, which the README links as its reference. So the tool can only remove redundant link lines if the metadata is structured to allow it. In practice this means a packager who has been listing every transitive dependency by hand in a .pc file will get less benefit from pkgconf, and a packager who has declared dependencies properly will get the deduplication the feature promises. The optimisations are described as things pkgconf can make when used effectively, which is a fair way to put a dependency on metadata quality.

## libpkgconf lets compilers and IDEs query the same metadata

The second artefact in the project is libpkgconf, a library that provides access to most of pkgconf's functionality, and the stated purpose is to let other tooling such as compilers and IDEs discover and use libraries configured by pkgconf. The practical effect is that the .pc file parsing, the dependency resolution and the flag computation are not locked inside a command line program. An editor that wants to show include paths for a project can use the same resolver the build uses instead of reimplementing the format. The README also draws a firm line around the debug output: only the stable interfaces should be used to query pkg-config, and the output of --debug should not be screen-scraped, because it is sent to stderr for a reason and is not intended to be scraped. The --debug output is not a stable interface and should never be depended on as a source of information, and if a stable interface you need is missing, the project asks to be contacted. That is a useful constraint to know, because script-driven tooling that has been parsing that output is the most likely thing to break.

## SBOM generators for the packages you actually depend on

Two small programs sit alongside the core tool. bomtool generates a software bill of materials for a given set of pkg-config modules in the SPDX 2.0 format, and spdxtool does the same in the SPDX Lite 3.0.1 format, and the README notes that the output of these tools can then be translated into other SBOM formats as necessary. The scope is deliberate: the bill of materials covers the pkg-config modules in question, which for a distribution builder is a reasonable definition of what a native dependency pulls in. Two limits are worth stating. The generation is driven by the .pc metadata, so anything a .pc file does not declare is not in the bill of materials, and the tool covers the pkg-config world only, not a whole operating system image. For a supply chain documentation exercise that is a starting point rather than a complete answer.

## Building with Meson, or with Muon when Python is missing

pkgconf uses Meson as its build system, and the README notes that if you want to use the git sources directly, or a snapshot of the sources from GitHub, Meson can be used directly without any additional bootstrap step. The normal sequence is three commands:

```bash
    $ meson setup build
    $ meson compile -C build
    $ meson install -C build
```

If you are installing into a custom prefix such as /opt/pkgconf, the default system includedir and libdir for your toolchain need to be defined, using the SYSTEM_LIBDIR and SYSTEM_INCLUDEDIR Meson options:

```bash
    $ meson setup build \
         --prefix=/opt/pkgconf \
         -DSYSTEM_LIBDIR=/lib:/usr/lib \
         -DSYSTEM_INCLUDEDIR=/usr/include
```

There are a few additional defines such as PKGCONFIGDIR, and on Windows the default PKGCONFIGDIR value is usually overridden at runtime based on path relocation. The bootstrap path deserves attention, because it is unusual. In bootstrap environments where Python is not yet available, pkgconf can be built with Muon, a C implementation of the Meson build description language, using the same meson.build files with no separate configuration, and both Meson and Muon are tested in CI.

## pkgconf-lite, the symlink decision, and how to reach the project

If you only need the original pkg-config functionality, there is also pkgconf-lite, which builds the pkgconf frontend and the relevant portions of libpkgconf into a single binary:

```bash
    $ make -f Makefile.lite
```

Separately, there is the question of whether pkgconf should answer to the name pkg-config. The README says that if you want pkgconf to be used when invoking pkg-config, you should install a symlink for this, and that the project does not do it for you, on the grounds that it is better for vendors to make that determination themselves:

```bash
    $ ln -sf pkgconf /usr/bin/pkg-config
```

That is a sensible position for a distribution, since the symlink is a policy decision with consequences for every build on the machine. The project is GPL-licensed with a COPYING file at the root, and the repository carries the usual set of files for a C project with autotools heritage, a Makefile.lite, a pkg.m4 file, a man directory, a fuzzer directory and test suites under t and tests. Bugs go to the GitHub issue tracker, there is a mailing list, and IRC is on the #pkgconf channel at irc.oftc.net. The release cadence is steady, with 3.0.8 on 2026-10-08, 3.0.9 on 2026-10-15 and 3.0.10 on 2026-10-19, and the last push was on 2026-10-19.

## Conclusion

pkgconf fits a distribution or toolchain builder that wants faster metadata resolution, virtual package support and a library other tools can link against, and that is prepared to fix .pc files rather than expect identical output to pkg-config. It does not fit a build that depends on byte-identical flags from the original, since the upstream project states it does not provide bug-level compatibility. Before switching a distribution over, install the pkg-config symlink deliberately, test the .pc files your own packages ship, and remember that the --debug output is explicitly not a stable interface, so any tooling that scrapes it will break.

## FAQ

### Is pkgconf a drop-in replacement for pkg-config?

No. The README states that pkgconf is a superset of the original functionality but does not provide bug-compatibility with pkg-config, and the bug compatibility section asks you to check that your .pc files are valid and follow the documented rules first.

### How do I build pkgconf from source?

With Meson: meson setup build, meson compile -C build and meson install -C build. In bootstrap environments without Python you can use Muon with muon setup build, samu -C build and muon install -C build, using the same meson.build files.

### How do I make pkgconf answer to the pkg-config name?

Install a symlink yourself, for example ln -sf pkgconf /usr/bin/pkg-config. The project deliberately does not do this for you, on the grounds that vendors should decide, and for a distribution the symlink is a policy decision affecting every build on the machine.

### What are bomtool and spdxtool used for?

They generate software bills of materials for a given set of pkg-config modules, in the SPDX 2.0 format for bomtool and SPDX Lite 3.0.1 for spdxtool, and the output can be translated into other SBOM formats as needed.

## Sources

- [Issues](https://github.com/pkgconf/pkgconf/issues)
- [pkgconf/pkgconf on GitHub](https://github.com/pkgconf/pkgconf)
- [README](https://github.com/pkgconf/pkgconf/blob/main/README.md)
- [Releases](https://github.com/pkgconf/pkgconf/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pkgconf-pkgconf