pkg-config issueshttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues2020-11-29T17:09:48Zhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/59pkg-config drops / marks of ${pcfiledir} causing builds to fail2020-11-29T17:09:48ZYaser Afsharpkg-config drops / marks of ${pcfiledir} causing builds to failpkg-config finds the .pr file in `MinGW-64` with no problem but replacing ${pcfiledir} in the file gives the wrong PATH.
where, `prefix=${pcfiledir}/../../`
e.g. it should be:
`-ID:/a/kimpy-test/KIM_API/lib/pkgconfig/../../include/kim-...pkg-config finds the .pr file in `MinGW-64` with no problem but replacing ${pcfiledir} in the file gives the wrong PATH.
where, `prefix=${pcfiledir}/../../`
e.g. it should be:
`-ID:/a/kimpy-test/KIM_API/lib/pkgconfig/../../include/kim-api`
but it would return
`-ID:akimpy-testKIM_APIlibpkgconfig/../../include/kim-api`
This does not happen on macOS or Linux. Is this an issue on `MinGW-64`?https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/57Reordering of arguments specified in the pkg-config.pc file.2020-10-08T16:13:41ZLinusReordering of arguments specified in the pkg-config.pc file.```sh
pkg-config --version
0.29.2
```
```sh
cat app.pc:
prefix=/opt/app
exec_prefix=${prefix}
libdir=${exec_prefix}/lib64
includedir=${exec_prefix}/include
Name: app
Description: app lib
Version: 0
Libs: -L ${libdir} -l app -Wl,-rpat...```sh
pkg-config --version
0.29.2
```
```sh
cat app.pc:
prefix=/opt/app
exec_prefix=${prefix}
libdir=${exec_prefix}/lib64
includedir=${exec_prefix}/include
Name: app
Description: app lib
Version: 0
Libs: -L ${libdir} -l app -Wl,-rpath=${libdir}
Cflags: -I${includedir}
```
```sh
pkg-config --cflags app
-I/opt/app/include
```
Changing the Cflags line to:
`Cflags: -I ${includedir}`
that is, with a space between -I and the path, causes the following, (arguments reordered):
```sh
pkg-config --cflags app
/opt/app/include -I
```
Considering that both POSIX and gcc specify `-I<SPACE>path` as valid command line arguments for the c99/gcc commands respectivly, I consider this to be a bug.
POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
```
c99 [options...] pathname [[pathname] [-I directory]
[-L directory] [-l library]]...
...
-I directory
```
GCC:
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Options
```
3.16 Options for Directory Search
These options specify directories to search for header files, for libraries and for parts of the compiler:
-I dir
```https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/56pkg-config drops quatation marks from command-line parameters causing builds ...2020-09-15T11:11:05ZTomas Ukkonenpkg-config drops quatation marks from command-line parameters causing builds to failOn MSYS2/MinGW64 environment you must use quatation marks in command-line parameters if path names have spaces (-L/c/path\ with\ spaces/lib/ => "-L/c/path with spaces/lib/").
Pkg-config silently drops those quatation marks even when th...On MSYS2/MinGW64 environment you must use quatation marks in command-line parameters if path names have spaces (-L/c/path\ with\ spaces/lib/ => "-L/c/path with spaces/lib/").
Pkg-config silently drops those quatation marks even when they are in .pc files. This causes builds to fail on Windows. (You must hand edit Makefiles to have output of pkg-config but with quatation marks again.)
Attached is dinrhiw.pc file which quatation marks are dropped by pkg-config.[dinrhiw.pc](/uploads/0a4b6f2b7b9365293695de1f833c7dd3/dinrhiw.pc)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/54Add a property to determine the type of a library2020-04-29T11:14:48ZVladimir StoiakinAdd a property to determine the type of a libraryCurrently pkg-config files have properties which provide building flags for using a project as a shared library and as a static library. But there is no way to determine what type of a library (shared, static or both) some pkg-config fil...Currently pkg-config files have properties which provide building flags for using a project as a shared library and as a static library. But there is no way to determine what type of a library (shared, static or both) some pkg-config file describes.
Because of this some projects have to use workarounds like merging Libs with Libs.private and Requires with Requires.private when the type of an external library is not known. Or the user should manually adjust the type before building a project. See, for example, this [PR](https://github.com/mesonbuild/meson/pull/3093) and references.
I suggest to introduce the property `Type: shared | static | both`, which will describe the type of a library. This will allow pkg-config to automatically select right set of flags.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/53pkg-config : List resolved module filenames for dependency tracking2020-03-30T12:21:37ZSimon Wattspkg-config : List resolved module filenames for dependency trackingWe have been seeing static link failures where a dependent module, somewhere down the dependency tree, has been modified, where the link arguments have been cached by cmake (FindPkgConfig).
It would be useful to have an output mode to r...We have been seeing static link failures where a dependent module, somewhere down the dependency tree, has been modified, where the link arguments have been cached by cmake (FindPkgConfig).
It would be useful to have an output mode to return a unique list the fully qualified paths for all the `.pc` files resolved by the search. These could then be used as dependencies in a similar manner to external include files.
Corresponding issue raised against cmake: [issue 205190](https://gitlab.kitware.com/cmake/cmake/-/issues/20519),https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/52PKG_CONFIG_SYSROOT_DIR and pcfiledir2021-02-26T06:49:42ZHeiko LewinPKG_CONFIG_SYSROOT_DIR and pcfiledirI've noticed a difference in behaviour when compared to pkgconf (https://github.com/pkgconf/pkgconf)
Given a .pc-file like
❯ cat /home/git/android-native/root/linux/lib/pkgconfig/wdyGrendel.pc
prefix=${pcfiledir}/../..
...
when calle...I've noticed a difference in behaviour when compared to pkgconf (https://github.com/pkgconf/pkgconf)
Given a .pc-file like
❯ cat /home/git/android-native/root/linux/lib/pkgconfig/wdyGrendel.pc
prefix=${pcfiledir}/../..
...
when called with a PKG_CONFIG_SYSROOT_DIR environment-variable, pkg-config adds the sysroot-prefix to to the pcfiledir, while pkgconf does not:
PKG_CONFIG_SYSROOT_DIR=/home/git/android-native/root/linux PKG_CONFIG_LIBDIR=/home/git/android-native/root/linux/lib/pkgconfig ./pkg-config --cflags wdyGrendel
-I/home/git/android-native/root/linux/home/git/android-native/root/linux/lib/pkgconfig/../../include
PKG_CONFIG_SYSROOT_DIR=/home/git/android-native/root/linux PKG_CONFIG_LIBDIR=/home/git/android-native/root/linux/lib/pkgconfig pkgconf --cflags wdyGrendel
-I/home/git/android-native/root/linux/lib/pkgconfig/../../include
Who is right?https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/51Is the test of "check-system-flags" right?2019-06-08T05:48:59ZSENOO, KenIs the test of "check-system-flags" right?* OS: Ubuntu 18.04
* Version: pkg-config 0.29.2 from Gitlab repository.
I tried installing pkg-config from Gitlab repository.
But `make check` failed with following message.
```
PASS: check-dependencies
../pkg-config --cflags system :...* OS: Ubuntu 18.04
* Version: pkg-config 0.29.2 from Gitlab repository.
I tried installing pkg-config from Gitlab repository.
But `make check` failed with following message.
```
PASS: check-dependencies
../pkg-config --cflags system :
'' != '-I/usr/include'
FAIL: check-system-flags
==============================================================================
1 of 30 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=pkg-config
==============================================================================
```
Failed line is following command in [check-system-flags](https://gitlab.freedesktop.org/pkg-config/pkg-config/blob/pkg-config-0.29.2/check/check-system-flags#L36).
```
PKG_CONFIG_SYSTEM_INCLUDE_PATH=/foo/include
PKG_CONFIG_SYSTEM_LIBRARY_PATH=/foo/lib
RESULT="-I/usr/include"
run_test --cflags system
```
I changed `common` file for testing Ubuntu 18.04 system pkg-config (v0.29.1).
```
-pkgconfig=${PKG_CONFIG-../pkg-config}
+pkgconfig=${PKG_CONFIG-pkg-config}
```
Then `make check` again. But system pkg-config has same failure.
Is this test command right? Can anyone pass the test of "check-system-flags"?https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/13can't define a macro as string literal with latest pkg-config2018-08-25T12:53:27ZBugzilla Migration Usercan't define a macro as string literal with latest pkg-config## Submitted by Qiu Wenbo
Assigned to **pkg..@..op.org**
**[Link to original bug (#107671)](https://bugs.freedesktop.org/show_bug.cgi?id=107671)**
## Description
I'm trying to define a string literal in cflags and I find pkg-confi...## Submitted by Qiu Wenbo
Assigned to **pkg..@..op.org**
**[Link to original bug (#107671)](https://bugs.freedesktop.org/show_bug.cgi?id=107671)**
## Description
I'm trying to define a string literal in cflags and I find pkg-config will strip the quotes automatically.
For example,
Cflags: -I${includedir}/somedir -DFOO="BAR"
and the output of pkg-config --cflags:
-I/usr/include/somedir -DFOO=BAR
I just want the macro FOO be defined as a string literal.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/17pkg-config --validate doesn't moan about multi-line description2018-08-25T12:53:50ZBugzilla Migration Userpkg-config --validate doesn't moan about multi-line description## Submitted by Olly Betts
Assigned to **pkg..@..op.org**
**[Link to original bug (#107038)](https://bugs.freedesktop.org/show_bug.cgi?id=107038)**
## Description
$ cat foo.pc
Name: foo
Description: An overly-long and pointlessly ...## Submitted by Olly Betts
Assigned to **pkg..@..op.org**
**[Link to original bug (#107038)](https://bugs.freedesktop.org/show_bug.cgi?id=107038)**
## Description
$ cat foo.pc
Name: foo
Description: An overly-long and pointlessly waffling description which has been
line-wrapped
URL: https://foo.example.org/
Version: 1.0
$ pkg-config --validate foo.pc && echo OK
OK
$ pkg-config --version
0.29
The documentation says:
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.
So the wrapped part of the Description on line 3 should really be reported as an invalid line.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/32man: Suggest using shell function from make to process pkg-config output corr...2018-08-25T12:55:21ZBugzilla Migration Userman: Suggest using shell function from make to process pkg-config output correctly.## Submitted by Tomasz Miąsko
Assigned to **pkg..@..op.org**
**[Link to original bug (#105461)](https://bugs.freedesktop.org/show_bug.cgi?id=105461)**
## Description
Created attachment 138029
[PATCH] man: Use shell function from m...## Submitted by Tomasz Miąsko
Assigned to **pkg..@..op.org**
**[Link to original bug (#105461)](https://bugs.freedesktop.org/show_bug.cgi?id=105461)**
## Description
Created attachment 138029
[PATCH] man: Use shell function from make to process pkg-config
pkg-config uses backslashes to escape special characters (including
spaces among others) in its --cflags and --libs output.
This is incompatible with command substitution as used in POSIX shell,
i.e., $(cmd ...) or `cmd ...`, because field splitting following such
substitution splits the result using sequences of `<space>`, `<tab>`, and
`<newline>` characters as separators (supposing default value of IFS).
Backslash does not have any special meaning in this process, and thus
escaping for those characters is ineffective.
Suggest using shell make function instead, which will expand the
results into the command output (converting newlines into spaces, but
not processing it further), and then when final command is executed
by POSIX shell, the shell tokenization rules will take into effect
which do respect backquotes and split input using unquoted `<blank>`
(`<space>` or `<tab>` in POSIX locale).
~~**Patch 138029**~~, "[PATCH] man: Use shell function from make to process pkg-config":
[0001-man-Use-shell-function-from-make-to-process-pkg-conf.patch](/uploads/ae53bc1cb84a51978d86b32c5cb16c75/0001-man-Use-shell-function-from-make-to-process-pkg-conf.patch)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/11windows: libdir variant for static linking2018-08-25T12:53:19ZBugzilla Migration Userwindows: libdir variant for static linking## Submitted by Clemens Buchacher
Assigned to **pkg..@..op.org**
**[Link to original bug (#105112)](https://bugs.freedesktop.org/show_bug.cgi?id=105112)**
## Description
Hi,
I am cross-compiling https://github.com/cliffordwolf/ic...## Submitted by Clemens Buchacher
Assigned to **pkg..@..op.org**
**[Link to original bug (#105112)](https://bugs.freedesktop.org/show_bug.cgi?id=105112)**
## Description
Hi,
I am cross-compiling https://github.com/cliffordwolf/icestorm.git for Windows 10 using mingw-w64 inside WSL (cross-compiling is what upstream has been doing, so I am trying to reuse that work). I already compiled the libftdi library dependency.
Upstream and others (https://rqou.com/jenkins/job/open-fpga-tools/job/icestorm-win64/691/console) seem to be hard-coding the libftdi library path to their install locations. I could be doing the same, but the icestorm Makefile already uses pkg-config, so we could make this work out of the box.
The problem is that libdir in libftdi1.pc points to $PREFIX/bin, rather than the lib directory, because shared libraries (DLLs) are typically installed in the same directory with the executable on Windows (they must be in the PATH or in the same directory with the executable for the dynamic linker to find it). The static library, however, is still installed in $PREFIX/lib.
What would you think about adding an optional alternative libdir, e.g. libdir_static, to indicate the location of static libraries, in case they are different from the location of the dynamic libraries?https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/20pkg.m4: add $PKG_VERSION to available variables.2021-10-04T12:34:22ZBugzilla Migration Userpkg.m4: add $PKG_VERSION to available variables.## Submitted by hanetzer `@hanetzer`
Assigned to **pkg..@..op.org**
**[Link to original bug (#104543)](https://bugs.freedesktop.org/show_bug.cgi?id=104543)**
## Description
Created attachment 136623
pkg.m4.in-modversion.patch
Occ...## Submitted by hanetzer `@hanetzer`
Assigned to **pkg..@..op.org**
**[Link to original bug (#104543)](https://bugs.freedesktop.org/show_bug.cgi?id=104543)**
## Description
Created attachment 136623
pkg.m4.in-modversion.patch
Occasionally one would like to be able to query the version
of a given package at build time, possibly to include into
debug messages or maybe the 'help->about' menu on their app
in order to list what version of a library a given program
is compiled against.
Its a trivial change as far as I can see, just a two-liner
patch unless there are some intricacies I'm missing. Find
attached a patch showing the needed changes made as far as
my admittedly limited knowledge of m4/autotools/etc shows.
**Attachment 136623**, "pkg.m4.in-modversion.patch":
[file_104543.txt](/uploads/15010b73228bf674fa19acdc0ffa4405/file_104543.txt)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/35script generated by pkg.m4 does not work when pkg-config is in a directory wi...2018-08-25T12:55:46ZBugzilla Migration Userscript generated by pkg.m4 does not work when pkg-config is in a directory with spaces## Submitted by Jefferson Carpenter
Assigned to **pkg..@..op.org**
**[Link to original bug (#103368)](https://bugs.freedesktop.org/show_bug.cgi?id=103368)**
## Description
Created attachment 134933
patch
When pkg-config is locate...## Submitted by Jefferson Carpenter
Assigned to **pkg..@..op.org**
**[Link to original bug (#103368)](https://bugs.freedesktop.org/show_bug.cgi?id=103368)**
## Description
Created attachment 134933
patch
When pkg-config is located in a directory with spaces, the script generated by pkg.m4 crashes whenever it tries to run the program.
For instance, when pkg-config is located in
C:\Program Files\Mono\bin\pkg-config.exe
I get the following messages from the configure script in cygwin:
./configure: line 2645: /cygdrive/c/Program: No such file or directory
I haven't tested, but this problem would also occur on Linux, should pkg-config ever be in a directory with spaces.
A patch is attached that should fix the problem with pkg-config. I have not looked for other commands in pkg.m4 that may have the same issue.
**Attachment 134933**, "patch":
[0001-Don-t-crash-when-pkg-config-is-in-a-path-containing-.patch](/uploads/5e5648d87915b34145954618c9927e16/0001-Don-t-crash-when-pkg-config-is-in-a-path-containing-.patch)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/43pkg-config output with escaped spaces cannot be used by Windows cmd2018-08-25T12:56:25ZBugzilla Migration Userpkg-config output with escaped spaces cannot be used by Windows cmd## Submitted by Maria
Assigned to **pkg..@..op.org**
**[Link to original bug (#103203)](https://bugs.freedesktop.org/show_bug.cgi?id=103203)**
## Description
Created attachment 134783
pc file used as an example
As I see Windows c...## Submitted by Maria
Assigned to **pkg..@..op.org**
**[Link to original bug (#103203)](https://bugs.freedesktop.org/show_bug.cgi?id=103203)**
## Description
Created attachment 134783
pc file used as an example
As I see Windows command line supports quotation marks only to escape spaces in a path. But pkg-config tool adds backslashes to escape spaces in a path.
Because of this it looks impossible to use pkg-config on Windows if include path or lib path contain spaces.
Example without spaces:
----------------------------------------------------------------------------
C:\tmp>for /F "delims=," %i in ('pkg-config --cflags --libs win-path-wspace-test') do cl x.c %i
C:\tmp>cl x.c -IC:\\tmp/include C:\\tmp/libs/a.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
x.c
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation. All rights reserved.
/out:x.exe
x.obj
C:\\tmp/libs/a.lib
----------------------------------------------------------------------------
Example with spaces:
----------------------------------------------------------------------------
C:\tmp>for /F "delims=," %i in ('pkg-config --cflags --libs win-path-wspace-test') do cl x.c %i
C:\tmp>cl x.c -IC:\\Program\ Files\ (x86)\\tmp/include C:\\Program\ Files\ (x86)\\tmp/libs/a.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9024 : unrecognized source file type 'Files\', object file assumed
cl : Command line warning D9024 : unrecognized source file type '(x86)\\tmp/include', object file assumed
cl : Command line warning D9024 : unrecognized source file type 'C:\\Program\', object file assumed
cl : Command line warning D9024 : unrecognized source file type 'Files\', object file assumed
x.c
x.c(3): fatal error C1083: Cannot open include file: 'a.h': No such file or directory
----------------------------------------------------------------------------
Could you add possibility to get quotation marks for those paths on Windows that contains spaces to escape them? So that it would be much easier to work with pkg-config on Windows.
And just nice-to-have: when I set path with spaces to PKG_CONFIG_PATH Windows command line adds quotation marks to this path automatically but path with quotation marks can not be found by pkg-config tool
From debug output:
----------------------------------------------------------------------------
C:\tmp>set PKG_CONFIG_PATH="C:\work\pkg config"
C:\tmp>pkg-config --cflags --libs --debug win-path-wspace-test
Option --debug seen
Error printing enabled by default due to use of --version, --libs, --cflags, --libs-only-l, --libs-only-L, --libs-only-other, --cflags-only-I, --cflags-only-other or --list. Value of --silence-errors: 0
Error printing enabled
Adding virtual 'pkg-config' package to list of known packages
Cannot open directory '"C:/tmp/pkg config"' in package search path: No such file or directory
----------------------------------------------------------------------------
**Attachment 134783**, "pc file used as an example":
[win-path-wspace-test.pc](/uploads/49fca8e16f0335dea4d63150ae6109de/win-path-wspace-test.pc)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/8pkg-config m4 macros treat empty FOO_CFLAGS, FOO_LIBS as unset2018-08-25T12:53:07ZBugzilla Migration Userpkg-config m4 macros treat empty FOO_CFLAGS, FOO_LIBS as unset## Submitted by Simon McVittie
Assigned to **pkg..@..op.org**
**[Link to original bug (#102622)](https://bugs.freedesktop.org/show_bug.cgi?id=102622)**
## Description
The recommended way to deal with libraries that might not have ...## Submitted by Simon McVittie
Assigned to **pkg..@..op.org**
**[Link to original bug (#102622)](https://bugs.freedesktop.org/show_bug.cgi?id=102622)**
## Description
The recommended way to deal with libraries that might not have working .pc metadata appears to be this:
> [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.])
and in the development branch of dbus, we've documented EXPAT_CFLAGS and EXPAT_LIBS as the way to avoid relying on pkg-config metadata for archaic or wrongly-installed versions of Expat (which seems to include SuSE's mingw32-expat, Bug #102613).
However, in a cross-compilation environment with a pre-configured cross-compiler, it's entirely possible that EXPAT_CFLAGS can legitimately be empty: for example, on Bug #102613, <expat.h> appears to already be on the cross-compiler's default search path, so no extra -I flag should be required.
The pkg-config macro ends up doing this:
> m4_define([_PKG_CONFIG],
> [if test -n "$$1"; then
> pkg_cv_[]$1="$$1"
> elif test -n "$PKG_CONFIG"; then
> ... rely on pkg-config ...
This means that if $1 (in this case EXPAT_CFLAGS) is set, but to an empty value, then we require .pc metadata.
Perhaps the macro should have this pseudo-patch:
m4_define([_PKG_CONFIG],
-[if test -n "$$1"; then
+[if test -n "${$1+set}"; then
pkg_cv_[]$1="$$1"
so that the decision is really between set vs. unset, rather than between (set && non-empty) vs. (unset || empty).https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/36Missing description field makes pkg-config --list-all silently fail2019-08-10T09:39:03ZBugzilla Migration UserMissing description field makes pkg-config --list-all silently fail## Submitted by Moses Miller
Assigned to **pkg..@..op.org**
**[Link to original bug (#101042)](https://bugs.freedesktop.org/show_bug.cgi?id=101042)**
## Description
A certain package called qt5-webkit-ng in my Linux distribution s...## Submitted by Moses Miller
Assigned to **pkg..@..op.org**
**[Link to original bug (#101042)](https://bugs.freedesktop.org/show_bug.cgi?id=101042)**
## Description
A certain package called qt5-webkit-ng in my Linux distribution ships a broken pkg-config file (https://ptpb.pw/j--R) which is missing the Description field, which *should* make `pkg-config --list-all` fail with an error or skip over that one package. However, when `pkg-config --list-all` is executed without the --debug argument, it fails silently, printing nothing to stderr or stdout.
Here is the output from `pkg-config --list-all --debug`: https://ptpb.pw/A78fhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/46pkg.m4 should check that $PKG_CONFIG is a pkg-config binary2018-08-25T12:56:47ZBugzilla Migration Userpkg.m4 should check that $PKG_CONFIG is a pkg-config binary## Submitted by Samuel Thibault `@sthibaul`
Assigned to **pkg..@..op.org**
**[Link to original bug (#100575)](https://bugs.freedesktop.org/show_bug.cgi?id=100575)**
## Description
Hello,
We have seen a user erroneously define PKG...## Submitted by Samuel Thibault `@sthibaul`
Assigned to **pkg..@..op.org**
**[Link to original bug (#100575)](https://bugs.freedesktop.org/show_bug.cgi?id=100575)**
## Description
Hello,
We have seen a user erroneously define PKG_CONFIG to its /usr/local/lib/pkgconfig, and thus all our configure.ac pkg-config tests were failing and we were wondering why... pkg.m4 should make sure that $PKG_CONFIG really is a binary (e.g. by running it with --help) and loudly error out otherwise.
Samuelhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/47pkg-config 0.29.1 check fails when building in mingw32+msys12018-08-25T12:56:50ZBugzilla Migration Userpkg-config 0.29.1 check fails when building in mingw32+msys1## Submitted by Elio Blanca
Assigned to **pkg..@..op.org**
**[Link to original bug (#95422)](https://bugs.freedesktop.org/show_bug.cgi?id=95422)**
## Description
I'm trying to get a simple, clean build of pkg-config in a windows x...## Submitted by Elio Blanca
Assigned to **pkg..@..op.org**
**[Link to original bug (#95422)](https://bugs.freedesktop.org/show_bug.cgi?id=95422)**
## Description
I'm trying to get a simple, clean build of pkg-config in a windows xp environment using mingw32 (not the newest mingw-W64) and msys1, with gcc-4.9.3 and binutils-2.25.1.
I enabled the '--with-internal-glib' option in order not to ship the final executable with huge several dll files. Build went ok, then when I launched 'make check' two tests failed:
[cut]
make[2]: Entering directory `/home/David/pkg-config-0.29.1/check'
PASS: check-cflags
PASS: check-libs
PASS: check-mixed-flags
PASS: check-non-l-flags
PASS: check-define-variable
PASS: check-libs-private
PASS: check-requires-private
PASS: check-circular-requires
PASS: check-includedir
PASS: check-conflicts
PASS: check-missing
PASS: check-special-flags
PASS: check-sort-order
PASS: check-duplicate-flags
PASS: check-whitespace
PASS: check-cmd-options
PASS: check-version
PASS: check-requires-version
PASS: check-print-options
../pkg-config.exe --variable=pc_path pkg-config :
'C:\MSYS_1\msys\1.0\home\David\pkg-config-0.29.1\lib\pkgconfig;C:\MSYS_1\msys\1.0\home\David\pkg-config-0.29.1\share\pkgconfig' != 'C:\MSYS_1\msys\1.0\home\David\pkg-config-0.29.1\.libs\lib\pkgconfig;C:\MSYS_1\msys\1.0\home\David\pkg-config-0.29.1\.libs\share\pkgconfig'
FAIL: check-path
PASS: check-sysroot
PASS: check-uninstalled
PASS: check-debug
PASS: check-gtk
PASS: check-tilde
PASS: check-relocatable
../pkg-config.exe --variable=prefix simple :
'C:/MSYS_1/msys/1.0/foo' != '/foo'
FAIL: check-variable-override
PASS: check-variables
[cut]
The code is from the vanilla tarball, maybe the git master has some latest useful fix? Can anybody help me fixing this?
Thank you
Eliohttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/24Add the ability to disable conflict checking2018-08-25T12:54:28ZBugzilla Migration UserAdd the ability to disable conflict checking## Submitted by Ed Baunton
Assigned to **Ed Baunton**
**[Link to original bug (#93272)](https://bugs.freedesktop.org/show_bug.cgi?id=93272)**
## Description
In my use case, I have a very large hierarchy of libraries (>1000) that n...## Submitted by Ed Baunton
Assigned to **Ed Baunton**
**[Link to original bug (#93272)](https://bugs.freedesktop.org/show_bug.cgi?id=93272)**
## Description
In my use case, I have a very large hierarchy of libraries (>1000) that need to be statically linked together. All the .pc files for this hierarchy are automatically generated by us (internal libraries) and thus we control how they look.
I notice that during the running of `pkg-config` it spends a large amount of time checking for conflicts which is not a feature we use in our automatic generation. Therefore, I would like the ability to disable this.
I can see two approaches whilst implementing this and would like to discuss which is more favourable.
1) Add a command-line option to disable conflict checking (`--disable-conflicts` or similar). Then this flag can simply be checked before running `recursive_fill_list` and users have explicitly opt-ed out.
2) Make `pkg-config` more intelligent and detect usage of the `conflicts` feature during hierarchy parsing. This has the benefit of speeding up all users of `pkg-config` by detecting whether the conflicts feature has been used and would skip the step of checking for them. However, this would inhibit users who specifically want to inhibit conflict checking in use-cases where they do not govern the generation of all PC files. Additionally, it is a little more invasive in terms of code (the file parsing routine would be have to be extended to produce and output variable for this use-case).https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/40Change system path variable to PKG_CONFIG_SYSTEM_PATH2018-08-25T12:56:04ZBugzilla Migration UserChange system path variable to PKG_CONFIG_SYSTEM_PATH## Submitted by Dan Nicholson `@dbn`
Assigned to **pkg..@..op.org**
**[Link to original bug (#89268)](https://bugs.freedesktop.org/show_bug.cgi?id=89268)**
## Description
PKG_CONFIG_LIBDIR overrides the builtin pkg-config path, bu...## Submitted by Dan Nicholson `@dbn`
Assigned to **pkg..@..op.org**
**[Link to original bug (#89268)](https://bugs.freedesktop.org/show_bug.cgi?id=89268)**
## Description
PKG_CONFIG_LIBDIR overrides the builtin pkg-config path, but you'd never know it from the name. Not only does it not say it's a path variable, but the standard path has also include a datadir arch-independent directory for years.
I propose to change this to PKG_CONFIG_SYSTEM_PATH, silently accepting PKG_CONFIG_LIBDIR for compatibility.