Pkg-config

Введение в pkg-config

http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>style=»clear:both;»>

pkg-config может использоваться для вывода соответствующей информации о библиотеке, такой как путь к библиотеке, путь к связанным файлам заголовков и т. д. Это будет очень полезно при компиляции программы. Например, теперь вы хотите скомпилировать программу, которая зависит от библиотеки librtmp.so. Где найти librtmp.so связанные заголовочные файлы? Где находится библиотека librtmp.so? Это большая проблема, но ни одна из них не является проблемой с pkg-config. Сначала взгляните на следующую команду:

Видя, что pkg-config может найти путь к заголовочному файлу, он также может найти, где находится инвентарь, и также может узнать другие библиотеки, от которых он зависит.

С помощью pkg-config, когда я компилирую программу для использования библиотеки librtmp.so, я могу написать:

Хахахаха, с pkg-config, маме никогда не придется беспокоиться о поиске библиотек, когда моя программа компилируется

Итак, возникает вопрос: откуда pkg-config узнает такую ​​информацию, как путь к инвентарю и файл заголовка?

Ответ находится в файле .pc. После того, как файл библиотеки скомпилирован, в каталоге {instal_home / lib /} будет создан каталог с именем pkgconfig, который содержит файл .pc связанной библиотеки. Этот файл содержит соответствующую информацию о модификации библиотеки. Чтобы найти и прочитать, необходимо установить файл .pc в каталог / usr / lib / pkgconfig / или добавить путь установки файла .pc в переменную среды PKG_CONFIG_PATH. Цель этого — позволить другим программам, которые зависят от этой библиотеки, автоматически связывать библиотеку с помощью pkg-config, избегая ошибок во время компиляции.

Общие параметры pkg-config:

—list-all Вывести список всех установленных общих библиотек —cflags Перечисляет флаги предварительной обработки и компиляции для указанной общей библиотеки. —libs Перечисляет флаги ссылок для указанной общей библиотеки.

Переменная окружения PKG_CONFIG_PATH используется для указания пути, где pkg-config ищет файлы .pc. Кроме того, pkg-config также будет искать файлы .pc в каталоге / usr / lib / pkgconfig /.

Установите переменную среды следующим образом: export PKG_CONFIG_PATH = / usr / local / lib

Интеллектуальная рекомендация

1. Для реальных сигналов (для понимания): A (ω) является соотношением амплитуды выходного сигнала и амплитуды входного сигнала, называемого частотой амплитуды. Φ (ω) — это разница межд…

Один. вести Многие люди задавали некоторые вопросы о создании проекта Flex + LCDS (FDS) в сообщениях и группах. Из-за операции ее трудно четко объяснить, поэтому я написал простой учебник (я обещал эт…

package com.example.phonehttp; import android.os.Bundle; import android.os.Handler; import android.app.Activity; import android.widget.ScrollView; import android.widget.TextView; public class MainActi…

Он предназначен для реализации подкласса того же родительского класса с родительским классом. Полиморфизм Один и тот же ссылочный тип использует разные экземпляры для выполнения разных операций; Идея …

тема: Объедините два упорядоченных слоя в новый заказанный список и возврат. Новый список состоит из всех узлов двух связанных списков, данных сплавным. Пример: Анализ: два связанных списка состоит в …

Вам также может понравиться

D. Самая ценная строка Пример ввода 2 2 aa aaa 2 b c Образец вывода aaa c На самом деле, будучи задетым этим вопросом, вы должны быть осторожны. После инвертирования строки, если две строки имеют один…

Given a 2D integer matrix M representing the gray scale of an image, you need to design a smoother to make the gray scale of each cell becomes the average gray scale (rounding down) of all the 8 surro…

calc () может быть очень незнакомым для всех, и трудно поверить, что calc () является частью CSS. Поскольку он выглядит как функция, почему он появляется в CSS, поскольку это функция? Этот момент такж…

Основываясь на дереве регрессии, сформированном CART, а также на предварительной и последующей обрезке дерева, код выглядит следующим образом:…

Откат Обновление в режиме онлайн с версии Centos (CentOS Linux версии 7.3.1611 (Core) до CentOS Linux версии 7.5.1804 (Core)) # ошибка соединения yum-ssh после обновления yexpected key exchange group …

Snapshot filesystem

During packaging process collects project files and places
them into executable. It is called a snapshot. At run time the
packaged application has access to snapshot filesystem where all
that files reside.

Packaged files have prefix in their paths (or
in Windows). If you used command line,
then value will be likely
at run time. will be as well. Here is
the comparison table of path-related values:

value	with	packaged	comments
__filename	/project/app.js	/snapshot/project/app.js
__dirname	/project	/snapshot/project
process.cwd()	/project	/deploy	suppose the app is called …
process.execPath	/usr/bin/nodejs	/deploy/app-x64	and run in
process.argv	/usr/bin/nodejs	/deploy/app-x64
process.argv	/project/app.js	/snapshot/project/app.js
process.pkg.entrypoint	undefined	/snapshot/project/app.js
process.pkg.defaultEntrypoint	undefined	/snapshot/project/app.js
require.main.filename	/project/app.js	/snapshot/project/app.js

Hence, in order to make use of a file collected at packaging
time ( a javascript file or serve an asset) you should
take , ,
or as a base for your path calculations.
For javascript files you can just or
because they use current by default. For assets use
. Learn more about
in
.

On the other hand, in order to access real file system at run time
(pick up a user’s external javascript plugin, json configuration or
even get a list of user’s directory) you should take
or .

Windows Specialities

If a .pc file is found in a directory that matches the usual conventions (i.e., ends with \lib\pkgconfig), the prefix for that package is assumed to be the
grandparent of the directory where the file was found, and the prefix variable is overridden for that file accordingly.

In addition to the PKG_CONFIG_PATH environment variable, the Registry keys HKEY_CURRENT_USER\Software\pkgconfig\PKG_CONFIG_PATH and
HKEY_LOCAL_MACHINE\Software\pkgconfig\PKG_CONFIG_PATH can be used to specify directories to search for .pc files. Each (string) value in these keys is
treated as a directory where to look for .pc files.

1 ответ

Цель строки в конце /etc/bash.bashrc, которая содержала синтаксическую ошибку, заключалась в том, чтобы добавить каталог в конец переменной среды PKG_CONFIG_PATH. Когда VARNAME — это имя переменной среды, содержащей текст, состоящий из нескольких : -сепарализованных записей, это обычная идиома для записи таких вещей, как VARNAME=$VARNAME:otherstuff. (Хотя VARNAME=»$VARNAME:otherstuff» часто лучше, см. Ниже.) В вашем случае ошибочное пространство было добавлено к PKG_CONFIG_PATH с левой стороны знака =, вызывая ошибку.

было добавлено ошибочное пространство , чтобы установить переменную среды PKG_CONFIG_PATH, затем переменную среды PKG_CONFIG_PATH просто удалить строку с синтаксической ошибкой

с конца /etc/bash.bashrc — лучший подход.

Если вам нужно установить PKG_CONFIG_PATH, однако, вы должны исправить ошибку синтаксиса, заменив ошибочное пространство в PKG_CONFIG PATH с _, поэтому он читает PKG_CONFIG_PATH:

Или вы можете просто установить эту переменную среды в другом месте. Системный файл bashrc не является обычно рекомендуемым местом для установки переменных среды. См. EnvironmentVariables для деталей.

Вы также можете видеть все или часть правой части задания, заключенного в двойные кавычки:

Хотя это не является строго необходимым (в Bash) , это можно считать стилистически предпочтительным. В большинстве ситуаций переменные среды, которые могут содержать пробелы, должны быть заключены в » » при расширении ($). Назначение — это исключение, где явная цитата строго не требуется.

Однако я повторяю, что это все, только если вам действительно нужно установить PKG_CONFIG_PATH. Если вы не знаете, как эта линия попала в /etc/bash.bashrc, я не рекомендую ее возвращать. Я рекомендую следовать рекомендациям в EnvironmentVariables , за исключением случаев, когда вам действительно необходимо выполнить определение неправильной конфигурации среды.

Наконец, если вам интересно Если вам нужно и как его интерпретировать, то это значит, что оболочка попыталась запустить команду под названием PKG_CONFIG. В вашей системе нет такой команды (и ее не должно быть). Поскольку второй _ в PKG_CONFIG_PATH был записан как пространство вместо этого, первое слово строки не было назначением (нет = перед первым пустым пространством), так что слово интерпретировалось как имя команды для запуска. Итак, оболочка попыталась запустить команду PKG_CONFIG со всем остальным в строке, интерпретированной как , общей идиомой , и она сообщила об command not found для PKG_CONFIG.

ответ дан
23 May 2018 в 02:37

Description

The pkg-config program is used to retrieve information about installed libraries in the system. It is typically used to compile and link against one
or more libraries. Here is a typical usage scenario in a Makefile:

program: program.c

cc program.c ‘pkg-config —cflags —libs gnomeui’

pkg-config retrieves information about packages from special metadata files. These files are named after the package, with the extension .pc.
By default, pkg-config looks in the directory prefix/lib/pkgconfig for these files; it will also look in the colon-separated (on Windows,
semicolon-separated) list of directories specified by the PKG_CONFIG_PATH environment variable.

The package name specified on the pkg-config command line is defined to be the name of the metadata file, minus the .pc extension. If a
library can install multiple versions simultaneously, it must give each version its own name (for example, GTK 1.2 might have the package name «gtk+» while GTK
2.0 has «gtk+-2.0»).

Differences from other solutions

libtool archives (.la files)

libtool uses specific archive file format (so-called .la files) to provide additional compiler and linker flags when linking against a library.

Implicit vs explicit use

libtool works implicitly whenever it is used to build a library or a program. In the former case, it creates the .la file with used flags; it latter, it reads those files and uses the flags stored in them.

pkg-config needs to be used explicitly. A library has to install .pc files explicitly, and the program built against it needs to query pkg-config explicitly in its build system.

Static vs dynamic linking

libtool provides no distinction between dynamic and static linking. In both cases, the complete list of dependant libraries is passed to linker.

pkg-config explicitly distinguishes between public and private dependencies. This way, when using dynamic linking only actually necessary libraries are passed to linker; and when using static linking, the complete list is used.

Build system-agnostic

libtool archives are usually useful only when libtool is used both to build the library and the final executable. pkg-config is designed to be build system-agnostic instead.

No absolute paths

For a long time Gentoo suffered an issue that libtool archives contained absolute paths to dependent library archives. Effectively, whenever libraries were moved to another library directory, all libraries depending on them became broken and required rebuild. Although the issue is currently worked-around in Gentoo by replacing absolute paths with relative library names, it is still the upstream behavior of libtool.

pkg-config expresses dependencies through package names, and thus is free by design of similar issues.

Custom -config applications

Many libraries provide custom applications of similar function, for example pcap-config. Those applications are compiled along with the library, and often have the relevant compiler & linker flags compiled into itself.

Cross-compilation support

Usually, custom -config applications are built for the specific platform the library is built for. Effectively, they are of no use when cross-compiling if the host is unable to execute code for the target platform.

pkg-config uses simple text files which are platform-independent. Thus, for cross-compilation to work it is only necessary to install pkg-config on the host system and set appropriate PKG_CONFIG_PATH.

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

• Name: A human-readable name for the library or package. This
  does not affect usage of the pkg-config tool, which uses the name
  of the .pc file.
• Description: A brief description of the package.
• URL: An URL where people can get more information about and
  download the package.
• Version: A string specifically defining the version of the
  package.
• Requires: A list of packages required by this package. The
  versions of these packages may be specified using the comparison operators
  =, <, >, <= or >=.
• Requires.private: A list of private packages required by this
  package but not exposed to applications. The version specific rules from
  the Requires field also apply here.
• Conflicts: An optional field describing packages that this one
  conflicts with. The version specific rules from the Requires
  field also apply here. This field also takes multiple instances of the
  same package. E.g., Conflicts: bar = 1.3.0.
• Cflags: The compiler flags specific to this package and any
  required libraries that don’t support pkg-config. If the required
  libraries support pkg-config, they should be added to
  Requires or Requires.private.
• Libs: The link flags specific to this package and any required
  libraries that don’t support pkg-config. The same rule as
  Cflags applies here.
• Libs.private: The link flags for private libraries required by
  this package but not exposed to applications. The same rule as
  Cflags applies here.

Переменные окружения

Введение

Переменная окружения — это именованный объект, который содержит определения, используемые одним или несколькими приложениями. Используя переменные окружения, можно очень легко изменить настройки для одного или нескольких приложений.

Наиболее важные переменные

В следующей таблице перечислен ряд переменных, используемых в системе Linux и описание их использования. Примеры их значений приведены после таблицы.

Variable	Description
PATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых система ищет исполняемые файлы. Если введенное имя это исполняемый файл (например, ls, rc-update или emerge), но если исполняемый файл не находится в каталоге из списка, то система не будет выполнять его (одна можно указать полный введен в качестве команды, такую как /bin/ls).
ROOTPATH	У этой переменной те же функцию, что и у PATH, но в ней содержатся только те каталоги, которые должны быть проверены, когда root-пользователь вводит команду.
LDPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых динамический линковщик ищет библиотеки.
MANPATH	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда man ищет страницы man.
INFODIR	Эта переменная содержит разделенный двоеточиями список каталогов, в которых команда info выполняет поиск страниц info.
PAGER	Эта переменная содержит путь к программе, используемой для отображения содержимого файлов (таких как less или more).
EDITOR	Эта переменная содержит путь к программе, используемой для изменения содержимого файлов (таких как nano или vi).
KDEDIRS	Эта переменная содержит разделенный двоеточиями список каталогов, содержащих специфический материал для KDE.
CONFIG_PROTECT	Эта переменная содержит разделенный пробелами список каталогов, которые должны быть защищены Portage при обновлении.
CONFIG_PROTECT_MASK	Эта переменная содержит разделенный пробелами список каталогов, которые не должны быть защищены Portage при обновлении.

Ниже приведен пример, содержащий все эти переменные:

Код Пример содержимого для вышеуказанных переменных

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"

Frequently asked questions

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

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(, )

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.

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

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.

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?

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) 2010 Dan Nicholson.
This document is licensed under the
GNU General Public License, Version 2
or any later version.

Определение переменных глобально

Для централизации определения переменных в Gentoo используется каталог /etc/env.d/. Внутри каталога есть несколько файлов, такие как 00basic, 05gcc и так далее, которые содержат переменные, необходимые программе из названия файла.

Например, когда установлен gcc, ebuild создает файл с названием 05gcc, который содержит определения следующих переменных:

Файл Переменные, используемые по умолчанию gcc

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

Другие дистрибутивы просят пользователя изменять или добавлять такие определения переменных окружения в /etc/profile или в других местах

С другой стороны, в Gentoo очень просто для пользователя (и для Portage) обслуживать и управлять переменными окружения без необходимости обращать внимание на многочисленные файлы, которые содержат переменные окружения.. Например, когда обновляется gcc, также обновляется и файл /etc/env.d/05gcc без малейшего участия пользователя.

Например, когда обновляется gcc, также обновляется и файл /etc/env.d/05gcc без малейшего участия пользователя.

От этого выигрывает как Portage, так и пользователь. Иногда пользователям необходимо установит определенную переменную окружения для всей системы. Например, возьмем переменную http_proxy. Чтобы не возиться с /etc/profile, пользователь может просто создать файл (скажем /etc/env.d/99local) и написать необходимое определения в нём:

Файл Настройка глобальной переменной

http_proxy="proxy.server.com:8080"

Используя один и тот же файл для всех пользовательских переменных можно получить компактный список переменных, которые были определены пользователем самостоятельно.

env-update

Несколько файлов в /etc/env.d/ определяют переменную PATH. Это не ошибка: когда выполняется команда env-update, она добавит другие определения перед обновлением переменного окружения, что позволяет просто добавлять для пакетов (или пользователей) свои собственные настройки переменного окружения без вмешательство в уже существующие значениями.

Сценарий env-update добавляет значения из файлов /etc/env.d/ в алфавитном порядке. Имена файлов должны начинаться с двух десятичных чисел.

Код Порядок обновления, используемый env-update

00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

Объединение переменных происходит не всегда, а только для следующих переменных: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH и PYTHONPATH. Для всех остальных переменных используется последнее значение (в алфавитном порядке файлов в /etc/env.d/).

Можно добавить больше переменных к списку объединяемых переменных, добавив имя переменной в одну из переменных COLON_SEPARATED или SPACE_SEPARATED (также внутри файла /etc/env.d/).

При запуске env-update, сценарий создаст все переменные окружения и поместит их в /etc/profile.env (который используется /etc/profile). Кроме того, сценарий на основе значения LDPATH создаст /etc/ld.so.conf. После этого он запустит ldconfig, чтобы пересоздать файл /etc/ld.so.cache, используемый динамическим компоновщиком.

Чтобы увидеть эффект работы env-update сразу после его запуска, выполните следующую команду, чтобы обновить окружение. Пользователи, которые устанавливали Gentoo сами, вероятно, вспомнят эту команду из инструкции по установке:

ЗаметкаКоманда выше обновит переменные только для текущего терминала, в новых консолях и их потомках. Таким образом, если пользователь работает в X11, ему нужно либо вводить source /etc/profile в каждом новом открытом терминале, либо перезагрузить X, так все новые терминалы получили новые переменные

Если используется менеджер входа, то необходимо стать root и перезагрузить сервис /etc/init.d/xdm.

ВажноНельзя использовать переменные оболочки для определения других переменных. Это означает, что такие вещи как (где $BAR это другая переменная) запрещены.

Расширение PKG — что это такое

Когда программистами разрабатывалось расширение .pkg, основной их задачей было упростить процесс установки системных компонентов. Цель неоспоримо была достигнута – установка и обновление легко выполняются при помощи директории с данным расширением. Установка ПО может осуществляться индивидуально или со скриптом, который отвечает за данный процесс.

Как в Windows выглядит архив с расширением .pkg

Основное назначение данного расширения:

• Используется в качестве установочных пакетов различных программ, адаптированных под продукцию компании Apple (IPhone, IPad, MacBook).
• Файлы с данным расширением используются для хранения профилей на платформе XboxLive (разработано корпорацией Microsoft).
• Используется система Symbian для хранения пользовательских данных, а также для сбора и хранения информации о параметрах и конфигурации в установочных пакетах встроенных и сторонних программных обеспечений.
• Активно используется компанией Sony для установки программного обеспечения на их игровые консоли PlayStation 3 и PlayStation 4.

Логотипы операционной системы Windows, MAC и Linux

Metadata File Syntax

To add a library to the set of packages pkg-config knows about, simply install a .pc file. You should install this file to
libdir/pkgconfig.

Here is an example file:

# This is a comment
prefix=/home/hp/unst   # this defines a variable
exec_prefix=${prefix}  # defining another variable in terms of the first
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: GObject                            # human-readable name
Description: Object/type system for GLib # human-readable description
Version: 1.3.1
URL: http://www.gtk.org
Requires: glib-2.0 = 1.3.1
Conflicts: foobar <= 4.5
Libs: -L${libdir} -lgobject-1.3
Libs.private: -lm
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib/include

Files have two kinds of line: keyword lines start with a keyword plus a colon, and variable definitions start with an alphanumeric string plus an equals
sign. Keywords are defined in advance and have special meaning to pkg-config; variables do not, you can have any variables that you wish (however, users
may expect to retrieve the usual directory name variables).

Note that variable references are written «${foo}»; you can escape literal «${» as «$${«.

Name:

This field should be a human-readable name for the package. Note that it is not the name passed as an argument to pkg-config.

Description:

This should be a brief description of the package

URL:

An URL where people can get more information about and download the package

Version:

This should be the most-specific-possible package version string.

Requires:

This is a comma-separated list of packages that are required by your package. Flags from dependent packages will be merged in to the flags reported for your
package. Optionally, you can specify the version of the required package (using the operators =, <, >, >=, <=); specifying a version allows
pkg-config to perform extra sanity checks. You may only mention the same package one time on the Requires: line. If the version of a package is
unspecified, any version will be used with no checking.

Conflicts:

This optional line allows pkg-config to perform additional sanity checks, primarily to detect broken user installations. The syntax is the same as
Requires: except that you can list the same package more than once here, for example «foobar = 1.2.3, foobar = 1.2.5, foobar >= 1.3», if you have
reason to do so. If a version isn’t specified, then your package conflicts with all versions of the mentioned package. If a user tries to use your package and
a conflicting package at the same time, then pkg-config will complain.

Libs:

This line should give the link flags specific to your package. Don’t add any flags for required packages; pkg-config will add those
automatically.

Libs.private:

This line should list any private libraries in use. Private libraries are libraries which are not exposed through your library, but are needed in the case
of static linking.

Cflags:

This line should list the compile flags specific to your package. Don’t add any flags for required packages; pkg-config will add those
automatically.

Troubleshooting

Error: ENOENT: no such file or directory, uv_chdir

This error can be caused by deleting the directory the application is
run from. Or, generally, deleting directory when the
application is running.

Error: ERR_INSPECTOR_NOT_AVAILABLE

This error can be caused by using variable to force to
run with the debug mode enabled. Debugging options are disallowed
, as pkg executables are usually used for production environments.
If you do need to use inspector, you can yourself.

Error: require(…).internalModuleStat is not a function

This error can be caused by using variable with some
bootstrap or options causing conflicts with pkg. Some
IDEs, such as VS Code, may add this env variable automatically.

You could check on Unix systems (Linux/macOS) in :

$ printenv | grep NODE

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.

• PKG_PROG_PKG_CONFIG(): Locates the
  pkg-config tool on the system and checks the version for
  compatibility.
• PKG_CHECK_EXISTS(MODULES, , ):
  Checks to see whether a particular set of modules exists.
• PKG_CHECK_MODULES(VARIABLE-PREFIX, MODULES, , ):
  Checks to see whether a particular set of modules exists. If so, it sets
  <VARIABLE-PREFIX>_CFLAGS and
  <VARIABLE-PREFIX>_LIBS according to the output from
  pkg-config --cflags and pkg-config --libs.