pkg-config issueshttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues2021-11-11T12:48:24Zhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/28--exists processing Requires.private creates unnecessary depencencies2021-11-11T12:48:24ZBugzilla Migration User--exists processing Requires.private creates unnecessary depencencies## Submitted by Mikhail Zabaluev
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#4738)](https://bugs.freedesktop.org/show_bug.cgi?id=4738)**
## Description
Carried over from the discussion on bug #3097.
Checkin...## Submitted by Mikhail Zabaluev
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#4738)](https://bugs.freedesktop.org/show_bug.cgi?id=4738)**
## Description
Carried over from the discussion on bug #3097.
Checking depencencies listed in the Requires.private field when performing
--exists effectively creates buildtime dependencies that are unnecessary for
pure dynamic builds.
For example, cairo now lists libpng12 in Requires.private, and every configure
script that tests for cairo now fails if libpng12.pc is not present, even though
libpng is not needed for all-dynamic linking.
Proposed solution: --exists should also ignore Requires.private unless --static
flag has been specified.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/42Output when package requirements are not met can be more helpful2018-08-25T12:56:22ZBugzilla Migration UserOutput when package requirements are not met can be more helpful## Submitted by Björn Lindqvist
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#5340)](https://bugs.freedesktop.org/show_bug.cgi?id=5340)**
## Description
Moved from: http://bugzilla.gnome.org/show_bug.cgi?id=3...## Submitted by Björn Lindqvist
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#5340)](https://bugs.freedesktop.org/show_bug.cgi?id=5340)**
## Description
Moved from: http://bugzilla.gnome.org/show_bug.cgi?id=319251
Output from pkg-config is not formatted, therefore the output can look like this:
cking for DEPENDENCIES... configure: error: Package requirements (
glib-2.0 >= 2.8.0, gtk+-2.0 >= 2.8.3, libxml-2.0 >=
2.6.12 libxslt >= 1.1.7 libgnomeui-2.0 >= 2.6.0
libglade-2.0 >= 2.3.1 gnome-vfs-2.0 >= 2.9.2
gnome-vfs-module-2.0 gconf-2.0
gnome-desktop-2.0 >= 2.9.91 libgnomeprint-2.2 >=
2.4.0 libgnomeprintui-2.2 >= 2.4.0 ) were not met.
You should also be told WHICH of the package requirements failed. Otherwise you
have to guess.Tollef Fog HeenTollef Fog Heenhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/26pkg.m4: Add link test2018-08-30T20:05:44ZBugzilla Migration Userpkg.m4: Add link test## Submitted by Elrond
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#6953)](https://bugs.freedesktop.org/show_bug.cgi?id=6953)**
## Description
I think, it would be helpful, if either PKG_CHECK_MODULES or a n...## Submitted by Elrond
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#6953)](https://bugs.freedesktop.org/show_bug.cgi?id=6953)**
## Description
I think, it would be helpful, if either PKG_CHECK_MODULES or a new macro would
try to compile/link a simple program with the just detected flags to make sure,
they really work.
This would catch trivial issues, like the .pc file existing, but the .a/.so not
existing.Tollef Fog HeenTollef Fog Heenhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/1pkg-config online documentation2018-08-25T12:52:18ZBugzilla Migration Userpkg-config online documentation## Submitted by Ed Catmur
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#7743)](https://bugs.freedesktop.org/show_bug.cgi?id=7743)**
## Description
It would be nice to have the pkg-config documentation online,...## Submitted by Ed Catmur
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#7743)](https://bugs.freedesktop.org/show_bug.cgi?id=7743)**
## Description
It would be nice to have the pkg-config documentation online, since it's not
always reflexive to go straight to the an page. Of course, if keeping it
synchronised (with the man page etc.) would be too much trouble...Tollef Fog HeenTollef Fog Heenhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/2Add a m4 function to pkg.m4 and calls both AC_ARG_ENABLE AND PKG_CHECK_MODULES2018-08-25T12:54:33ZBugzilla Migration UserAdd a m4 function to pkg.m4 and calls both AC_ARG_ENABLE AND PKG_CHECK_MODULES## Submitted by Petteri Räty
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#13884)](https://bugs.freedesktop.org/show_bug.cgi?id=13884)**
## Description
I often up doing something like:
AC_ARG_ENABLE(`<pkg>`, AC_H...## Submitted by Petteri Räty
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#13884)](https://bugs.freedesktop.org/show_bug.cgi?id=13884)**
## Description
I often up doing something like:
AC_ARG_ENABLE(`<pkg>`, AC_HELP_STRING([--enable-`<pkg>`], [enable `<pkg>` support], [], [enable_`<pkg>`=auto]))
PKG_CHECK_MODULES(`<PKG>`, [`<pkg>` >= `<version>`],
[if test x"${enable_`<pkg>`}" = x"yes" || test x"${enable_`<pkg>`}" = x"auto"; then
AC_DEFINE(HAVE_`<PKG>`, 1, [defined if `<pkg>` is available])
fi],
[test x"${enable_`<pkg>`}" = x"yes" && AC_MSG_ERROR(`<pkg>` support needs `<pkg>` >= `<version>` installed)])
AC_SUBST(`<PKG>`_CFLAGS)
AC_SUBST(<PKG_LIBS)
IMHO it would be create if pkg-config provide a PKG_ macro for this so that one
could just do
PKG_ARG_ENABLE([`<pkg>`], [" >= `<version>`"], AC_DEFINE(HAVE_`<PKG>`, 1, [defined if `<pkg>` is available])https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/23Add Requires.cflags2018-08-25T12:54:22ZBugzilla Migration UserAdd Requires.cflags## Submitted by Behdad Esfahbod
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#18815)](https://bugs.freedesktop.org/show_bug.cgi?id=18815)**
## Description
According to Loïc Minier [1] pkg-config was recently ...## Submitted by Behdad Esfahbod
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#18815)](https://bugs.freedesktop.org/show_bug.cgi?id=18815)**
## Description
According to Loïc Minier [1] pkg-config was recently modified to recursively collect the cflags of Requires.private modules referenced. I believe using Requires.private for two completely separate purposes (libraries to be linked statically, and cflags needed for our headers) is totally bogus.
I suggest that the Requires.private change be reverted and a new tag Requires.cflags be added that only fetches cflags of the modules. For symmetry a Requires.libs tag may as well be added. To keep backward compatibility, you can leave Requires.private alone and add Requires.libs.private with the new semantics.
The use cases for Requires, Requires.cflags, and Requires.libs.private are very clear and separate:
- Requires: "cairo-xlib" for example requires "cairo" and "xlib". It makes little sense to be using cairo-xlib functions but not linking to cairo and xlib. Though it's not impossible. This is more of a convenience case.
- Requires.cflags: Used with modules that we use (as in #include) in our public headers. For example, "vte.h" includes "pango.h", "gtk.h", and "glib.h", but it's understandable that not every vte-using application may use those libraries. So vte must Requires.cflags: pango gtk glib, to not force linking to those.
- Requires.libs.private: This is completely implementation details of the module. For example, harfbuzz may use glib internally, but it doesn't expose any glib-related api nor does it include glib.h from its public headers. The only use for making this information available to users of harfbuzz is solely for static linking purposes.
Cheers,
behdad
[1] http://bugzilla.gnome.org/show_bug.cgi?id=322240
### Depends on
* [Bug 63747](https://bugs.freedesktop.org/show_bug.cgi?id=63747)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/33separation of CPPFLAGS/CFLAGS, LDFLAGS/LIBS2023-09-26T09:25:46ZBugzilla Migration Userseparation of CPPFLAGS/CFLAGS, LDFLAGS/LIBS## Submitted by Stefan Kost
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#19306)](https://bugs.freedesktop.org/show_bug.cgi?id=19306)**
## Description
pkg-config does not separate:
- CPPFLAGS and CFLAGS (both...## Submitted by Stefan Kost
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#19306)](https://bugs.freedesktop.org/show_bug.cgi?id=19306)**
## Description
pkg-config does not separate:
- CPPFLAGS and CFLAGS (both in --cflags)
- LDFLAGS and LIBADD/LDADD (both in --libs)
That is a bit troublesome when used with automake (it can override what people specify when running ./configure ... CPPFLAGS=-D..."). People are forced to put the output of --cflags into CFLAGS even though its mostly -I and -D stuff. For --libs its probably less critical as it should mostly contain -L and -l and not any other linker directives.
Any idea how to solve this?Tollef Fog HeenTollef Fog Heenhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/38Feature-Request: Cflags.private2021-09-30T17:12:13ZBugzilla Migration UserFeature-Request: Cflags.private## Submitted by Volker Grabsch
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#47996)](https://bugs.freedesktop.org/show_bug.cgi?id=47996)**
## Description
The Libs.private setting is a very handy way to handle...## Submitted by Volker Grabsch
Assigned to **Tollef Fog Heen `@tfheen`**
**[Link to original bug (#47996)](https://bugs.freedesktop.org/show_bug.cgi?id=47996)**
## Description
The Libs.private setting is a very handy way to handle static as well as shared library builds.
However, when (cross-)compiling for the Windows platform, this is not sufficient. The libraries need extra "dllexport" declarations in the headers when building a shared library. Those can usually be suppressed (for static linking) by something like -DTHISLIBRARY_STATIC. It would avoid lots of nasty code if "pkg-config --cflags" could take care of that. It might be as simple as:
Cflags.privat: -DTHISLIBRARY_STATIC
Would you accept a patch that implements this feature?
See also:
http://sourceforge.net/tracker/?func=detail&atid=101032&aid=3511842&group_id=1032#artifact_comment_6232799
### Depends on
* [Bug 63747](https://bugs.freedesktop.org/show_bug.cgi?id=63747)Tollef Fog HeenTollef Fog Heenhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/37Spec current metadata syntax2018-08-25T12:55:52ZBugzilla Migration UserSpec current metadata syntax## Submitted by Dan Nicholson `@dbn`
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#63747)](https://bugs.freedesktop.org/show_bug.cgi?id=63747)**
## Description
pkg-config has a de-facto metadata syntax that it's h...## Submitted by Dan Nicholson `@dbn`
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#63747)](https://bugs.freedesktop.org/show_bug.cgi?id=63747)**
## Description
pkg-config has a de-facto metadata syntax that it's held to for years now. This is well understood by people, but what exactly pkg-config will accept is not well documented. Furthermore, there are ways the metadata could be improved to add functionality, but changing the behavior would be really harmful since older versions wouldn't know how to cope with it. Here's a plan to deal with that:
1. A new optional field is added that declares what version of the pkg-config metadata syntax it uses. In the absence of this field, version 1 is assumed. My suggestion for the name is SpecVersion.
2. The currently accepted metadata is specified as version 1 so that .pc file writers know exactly pkg-config or any other program handling .pc files know what to write.
3. Release pkg-config-1.0 that covers version 1 of the metadata specification. After that, the metadata can be changed by bumping the spec version. .pc file writers can then opt-in to the newer syntax in a controlled way.
Michał Górny submitted a spec a while ago on the mailing list.
http://lists.freedesktop.org/archives/pkg-config/2012-September/000884.html
This document goes far beyond specifying the .pc metadata syntax. In particular, it specs the implementation details of the pkg-config program, which I don't think we want to get into. Still, it provides a solid starting point for a spec.
### Blocking
* [Bug 18815](https://bugs.freedesktop.org/show_bug.cgi?id=18815)
* [Bug 47996](https://bugs.freedesktop.org/show_bug.cgi?id=47996)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/22--cflags should return also default include dir for use with fortran2018-08-25T12:54:16ZBugzilla Migration User--cflags should return also default include dir for use with fortran## Submitted by augh
Assigned to **pkg..@..op.org**
**[Link to original bug (#65299)](https://bugs.freedesktop.org/show_bug.cgi?id=65299)**
## Description
I know, fortran is so clumsy that nobody want to use it. However it is wide...## Submitted by augh
Assigned to **pkg..@..op.org**
**[Link to original bug (#65299)](https://bugs.freedesktop.org/show_bug.cgi?id=65299)**
## Description
I know, fortran is so clumsy that nobody want to use it. However it is widely used in scientific community. Fortran does not use any "standard" include path. Even if include files (headers or "modules") are in, e.g., /usr/include, it needs -I/usr/include when invoked.
A --fortran option that would turn pkg-config behaviour to return also "standard" locations would be useful.
aughhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/3A corrupted string is returned for paths containing UTF-8 characters2018-08-25T12:52:27ZBugzilla Migration UserA corrupted string is returned for paths containing UTF-8 characters## Submitted by Nikos Chantziaras
Assigned to **pkg..@..op.org**
**[Link to original bug (#65503)](https://bugs.freedesktop.org/show_bug.cgi?id=65503)**
## Description
When a *.pc file contains paths with UTF-8 characters in them,...## Submitted by Nikos Chantziaras
Assigned to **pkg..@..op.org**
**[Link to original bug (#65503)](https://bugs.freedesktop.org/show_bug.cgi?id=65503)**
## Description
When a *.pc file contains paths with UTF-8 characters in them, pkg-config returns a corrupted string sequence (which appears as gibberish on the terminal.)
To reproduce, glib-2.0.pc can be temporarily edited to contain this:
includedir=${prefix}/τεστ
This results in:
$ pkg-config glib-2.0 --cflags
-I/usr/\�\�\�\�\�\�\�\�/glib-2.0 -I/usr/lib64/glib-2.0/include
Because of this, packages using this will fail to build.
I'm using pkg-config 0.28 on Gentoo Linux AMD64.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/44Build of pkg-config-0.28 fails 4 of 25 tests on MinGW-4.7.2/MSYS/Wine-1.6-rc42018-08-25T12:56:40ZBugzilla Migration UserBuild of pkg-config-0.28 fails 4 of 25 tests on MinGW-4.7.2/MSYS/Wine-1.6-rc4## Submitted by Alan W. Irwin
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#66939)](https://bugs.freedesktop.org/show_bug.cgi?id=66939)**
## Description
Created attachment 82458
compressed full build and test log ...## Submitted by Alan W. Irwin
Assigned to **Dan Nicholson `@dbn`**
**[Link to original bug (#66939)](https://bugs.freedesktop.org/show_bug.cgi?id=66939)**
## Description
Created attachment 82458
compressed full build and test log for my platform
"configure --with-internal-glib" (with CFLAGS set to -march=native which was necessary), "make" and "make install" succeed without issues, but
"make check" gives the following excerpted results:
FAIL: check-print-options
FAIL: check-path
FAIL: check-sysroot
FAIL: check-debug
4 of 25 tests failed
Note I installed MinGW-4.7.2 and MSYS using mingw-get-inst-20120426.exe with full updates then downgraded one component to msys-core-bin=1.0.17-1 following the directions at http://sourceforge.net/p/mingw/bugs/1950. Also I use the Wine-1.6-rc4 version of Windows that I built on Debian Wheezy. This MinGW-4.7.2/MSYS/Wine-1.6-rc4 platform has proved to be a reliable build platform for other much more complex software (e.g., wxwidgets). Nevertheless, the unique properties of my platform could be the issue here. Furthermore, I installed MinGW and MSYS with a unique installation prefix (where the appropriate bin directories are on the PATH, but the above failing pkg-config tests may require more information than that).
Because of the platform caveats probably the first order of business should be to attempt to replicate the issue for the latest MinGW/MSYS on a Microsoft version of the Windows platform. But if the pkg-config developers are interested in more of the details for my particular platform, I have attached a gzip compressed file containing the complete log of the build up to the test failures.
**Attachment 82458**, "compressed full build and test log for my platform":
[build_pkg-config.out.gz](/uploads/bfd4a46d08a8ecac45ea5e7c19890679/build_pkg-config.out.gz)Dan NicholsonDan Nicholsonhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/29internal glib needs updated due to obsolete automake2021-09-23T01:16:00ZBugzilla Migration Userinternal glib needs updated due to obsolete automake## Submitted by Alexander von Gluck IV `@kallisti5`
Assigned to **pkg..@..op.org**
**[Link to original bug (#67683)](https://bugs.freedesktop.org/show_bug.cgi?id=67683)**
## Description
cd pkg-config-0.28
mkdir -p m4
...## Submitted by Alexander von Gluck IV `@kallisti5`
Assigned to **pkg..@..op.org**
**[Link to original bug (#67683)](https://bugs.freedesktop.org/show_bug.cgi?id=67683)**
## Description
cd pkg-config-0.28
mkdir -p m4
libtoolize --force --copy --install
aclocal --install -I m4
autoreconf
automake
autoconf
COMMON_DOCS=`finddir B_COMMON_DOCUMENTATION_DIRECTORY`
./configure --prefix=`finddir B_COMMON_DIRECTORY` \
--datadir=`finddir B_COMMON_DATA_DIRECTORY` \
--docdir=$COMMON_DOCS/doc/pkg-config \
--mandir=$COMMON_DOCS/man \
--with-internal-glib
make
~> haikuporter -i pkgconfig-0.28
Matching License (GNU GPL v2) found in /boot/system/data/licenses
No dependencies
File already exists: /boot/common/develop/haikuports/dev-util/pkgconfig/download/pkg-config-0.28.tar.gz
Skipping download ...
Calculating checksum - OK
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./config.guess'
libtoolize: copying file `./config.sub'
libtoolize: copying file `./install-sh'
libtoolize: copying file `./ltmain.sh'
libtoolize: warning: no serial number on `/boot/common/data/aclocal/libtool.m4', not copying.
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:291: error: 'AM_PROG_CC_STDC': this macro is obsolete.
You should simply use the 'AC_PROG_CC' macro instead.
Also, your code should no longer depend upon 'am_cv_prog_cc_stdc',
but upon 'ac_cv_prog_cc_stdc'.
/boot/common/data/aclocal-1.13/obsolete-err.m4:17: AM_PROG_CC_STDC is expanded from...
configure.ac:291: the top level
autom4te: /boot/common/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
Traceback (most recent call last):
File "/boot/common/bin/haikuporter", line 1228, in `<module>`
haikuporter = HaikuPorter(options, args)
File "/boot/common/bin/haikuporter", line 295, in __init__
self.buildPort()
File "/boot/common/bin/haikuporter", line 787, in buildPort
self.runCommandSequence(self.bepKeys['BUILD'], self.workDir)
File "/boot/common/bin/haikuporter", line 1023, in runCommandSequence
check_call(commandString, shell=True, cwd=dir, env=shellEnv)
File "/boot/common/lib/python2.6/subprocess.py", line 488, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'set -e
cd pkg-config-0.28
mkdir -p m4
libtoolize --force --copy --install
aclocal --install -I m4
autoreconf
automake
autoconf
COMMON_DOCS=`finddir B_COMMON_DOCUMENTATION_DIRECTORY`
./configure --prefix=`finddir B_COMMON_DIRECTORY` \
--datadir=`finddir B_COMMON_DATA_DIRECTORY` \
--docdir=$COMMON_DOCS/doc/pkg-config \
--mandir=$COMMON_DOCS/man
make
' returned non-zero exit status 1https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/4macport installation fails to find 'ac_nonexistent.h'2023-09-26T09:23:12ZBugzilla Migration Usermacport installation fails to find 'ac_nonexistent.h'## Submitted by Koray Kalmaz
Assigned to **pkg..@..op.org**
**[Link to original bug (#69901)](https://bugs.freedesktop.org/show_bug.cgi?id=69901)**
## Description
Created attachment 86766
/opt/local/var/macports/logs/_opt_local_va...## Submitted by Koray Kalmaz
Assigned to **pkg..@..op.org**
**[Link to original bug (#69901)](https://bugs.freedesktop.org/show_bug.cgi?id=69901)**
## Description
Created attachment 86766
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/main.log
# port install pkgconfig command fails to install pkg-config with the following output;
Error: Failed to configure pkgconfig, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/work/pkg-config-0.28/config.log
Error: org.macports.configure for port pkgconfig returned: configure failure: command execution failed
Please see the log file for port pkgconfig for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/main.log
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port pkgconfig failed
bash-3.2# port install pkgconfig
---> Computing dependencies for pkgconfig
---> Configuring pkgconfig
Error: Failed to configure pkgconfig, consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/work/pkg-config-0.28/config.log
Error: org.macports.configure for port pkgconfig returned: configure failure: command execution failed
Please see the log file for port pkgconfig for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/main.log
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port pkgconfig failed
**Attachment 86766**, "/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_pkgconfig/pkgconfig/main.log":
[main.log](/uploads/ec1111de26253039d470ddcb180e994f/main.log)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/16Request to spin up a new version of pkg-config with ppc64le support.2018-08-25T12:53:43ZBugzilla Migration UserRequest to spin up a new version of pkg-config with ppc64le support.## Submitted by Chandan
Assigned to **pkg..@..op.org**
**[Link to original bug (#73246)](https://bugs.freedesktop.org/show_bug.cgi?id=73246)**
## Description
We are adding support for new ppc64le (IBM powerPC Little Endian)
archit...## Submitted by Chandan
Assigned to **pkg..@..op.org**
**[Link to original bug (#73246)](https://bugs.freedesktop.org/show_bug.cgi?id=73246)**
## Description
We are adding support for new ppc64le (IBM powerPC Little Endian)
architecture as part of which we are looking at all the packages that
need update.
I was looking at pkg-config (from repository
git://anongit.freedesktop.org/pkg-config and pkg-config-0.28 as well)
and was failed to build pkg-config on ppc64le machine because of
outdated config.guess.
Automake version of 1.13.4 onward has the support of ppc64le.
Would it be possible for you to spin up a newer version of
"pkg-config" by using the automake-1.13.4 or above?
I can help to validate the new release tarball of the "pkg-config"
works well by compiling on ppc64le machine.
Appreciate your response.
Thanks,
Chandanhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/34Better support for uninstalled frameworks2018-08-25T12:55:40ZBugzilla Migration UserBetter support for uninstalled frameworks## Submitted by Michael C. Grant
Assigned to **pkg..@..op.org**
**[Link to original bug (#73372)](https://bugs.freedesktop.org/show_bug.cgi?id=73372)**
## Description
As you probably know, Mac OSX has the concept of "Frameworks" t...## Submitted by Michael C. Grant
Assigned to **pkg..@..op.org**
**[Link to original bug (#73372)](https://bugs.freedesktop.org/show_bug.cgi?id=73372)**
## Description
As you probably know, Mac OSX has the concept of "Frameworks" that encapsulates shared libraries, header files, and the like into a convenient package. Users specify a framework to be used using the "-framework `<fname>`" argument. If the framework is not in a standard system location, it is necessary to precede this with an additional "-F`<path>`" argument as well. These two argument types are analogous to "-l" and "-L" library arguments, respectively.
So you probably know where this is going, because I've seen discussion of it in earlier pkg-config mailing lists... can we better support these flags in pkg-config?
Options:
--- Include "-framework `<fname>`" arguments when calling "pkg-config --libs-only-l", and "-F`<path>`" when using "pkg-config --libs-only-L".
--- Create new options that are suited specifically for frameworks; e.g., --frameworks-only-f and --frameworks-only-F.
--- Create--libs-only-lf and --libs-only-LF that retrieve both library and framework data simultaneously.
The advantage of the first approach is that many packages that rely on pkg-config for library discovery will suddenly "just work" on a Mac if their dependencies are provided in framework form. For instance, Qt is provided as a framework on the Mac; and if installed via Homebrew, it does not appear in the system path. So we would like to see things like this:
LDFLAGS+=-F/usr/local/Cellar/qt/4.8.5/lib
LIBS+=-framework QtCore -framework QtGui -framework QtNetwork
The disadvantage of the first approach is that the mnemonic value of the command-line options --libs-only-l and --libs-only-L are damaged. My personal opinion is that this is outweighed by the benefits. The second and third approaches will require many existing configure scripts to be changed to add these new framework-specific calls.
I will say that a fix here goes hand in hand with a patch I have proposed for libtool (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16384). In that case, I modified libtool to treat -F in the same manner as it currently treats -L; and in doing so, I ensure that the framework paths are properly passed to the linker. Note that libtool *already* treats -framework arguments properly; it was just -F that needed fixing.
I'm willing to work on a patch here if a consensus can be reached.https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/303 of 25 tests failed in MinGW environment with --use-internal-glib2018-08-25T12:55:05ZBugzilla Migration User3 of 25 tests failed in MinGW environment with --use-internal-glib## Submitted by fea..@..il.com
Assigned to **pkg..@..op.org**
**[Link to original bug (#76632)](https://bugs.freedesktop.org/show_bug.cgi?id=76632)**
## Description
Created attachment 96409
standard error and output streams from `...## Submitted by fea..@..il.com
Assigned to **pkg..@..op.org**
**[Link to original bug (#76632)](https://bugs.freedesktop.org/show_bug.cgi?id=76632)**
## Description
Created attachment 96409
standard error and output streams from `./configure --prefix=/ --use-internal-glib`, `make`, and `make check`
`make check` output excerpt below. Outputs from configure, `make`, and `make check` are attached. (I had quite a few warnings. Maybe they're related to this problem?)
make[1]: Entering directory `/redland/pkg-config-0.28/check'
make check-TESTS
make[2]: Entering directory `/redland/pkg-config-0.28/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-idirafter
PASS: check-sort-order
PASS: check-duplicate-flags
PASS: check-whitespace
PASS: check-cmd-options
PASS: check-version
PASS: check-requires-version
../pkg-config.exe --version --modversion simple :
'0.28
Ignoring incompatible output option "--modversion"' != 'Ignoring incompatible ou
tput option "--modversion"
0.28'
FAIL: check-print-options
../pkg-config.exe --variable=pc_path pkg-config :
'C:\Users\geneg\dev\Botanibank.fossil\redland\pkg-config-0.28\.libs\lib\pkgconfi
g;C:\Users\geneg\dev\Botanibank.fossil\redland\pkg-config-0.28\.libs\share\pkgco
nfig' != '\/\/lib\/pkgconfig:\/\/share\/pkgconfig'
FAIL: check-path
../pkg-config.exe --cflags public-dep :
'-IC:/Users/geneg/dev/Botanibank.fossil/MinGW/msys/1.0/sysroot/public-dep/includ
e' != '-I/sysroot/public-dep/include'
FAIL: check-sysroot
PASS: check-uninstalled
PASS: check-debug
PASS: check-gtk
PASS: check-tilde
==============================================================================
3 of 25 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=pkg-config
==============================================================================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/redland/pkg-config-0.28/check'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/redland/pkg-config-0.28/check'
make: *** [check-recursive] Error 1
**Attachment 96409**, "standard error and output streams from `./configure --prefix=/ --use-internal-glib`, `make`, and `make check`":
[3_of_25_tests_failed_MinGW_MSYS.zip](/uploads/ced567103c8e0c727c9c3f82132fe6fc/3_of_25_tests_failed_MinGW_MSYS.zip)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/25list-all command stops listing results when encounters serious error in any p...2018-08-25T12:54:33ZBugzilla Migration Userlist-all command stops listing results when encounters serious error in any package## Submitted by Tadeusz Szczyrba
Assigned to **pkg..@..op.org**
**[Link to original bug (#76791)](https://bugs.freedesktop.org/show_bug.cgi?id=76791)**
## Description
Created attachment 96614
Implement parser control logic in plac...## Submitted by Tadeusz Szczyrba
Assigned to **pkg..@..op.org**
**[Link to original bug (#76791)](https://bugs.freedesktop.org/show_bug.cgi?id=76791)**
## Description
Created attachment 96614
Implement parser control logic in place of exit() when error occurs
pkg-config's parser control logic seems to be pretty simple - any serious error in parsed package description and pkg-config outputs descriptive error message and exits. The exit() calls are used internally in many places in parser.
Unfortunately such an approach causes --list-all command to stop outputting data as soon as any serious error in one of the listed packages is found.
This is something rather unexpected - no one probably expects shortened packages listing where the only assumption if the package will be listed or not is if the package would be listed before or after erroneus package.
I would suggest two solutions:
1) first scan & parse all packages' .pc files and if any error occurs only print out error message with information which package caused error - if no error occured during parsing print out packages' description in format of '--list-all' command.
The approach seems to be simpler to implement and could be clearer indication that something is wrong with .pc files in one or more of scanned directories.
2) scan and output info about all .pc files which doesn't cause problems to stdout and descriptive errors to stderr about the packages which are not linkable because of errors in their .pc files.
The approach has the advantage that all the working .pc files are listed in --list-all commands and the possible trashes don't cause the software to work.
And --list-all command is possibly very useful for IDEs to get information which packages are available in the system to handle external dependiences (valama ide is one of such IDEs ).
I've implemented solution for the (2) - patch included for 0.28. The patch changes all exit() calls in parser to graceful returns with checks in callers if some problems occured to skip the package.
'make check' performed - all 25 tests successful.
The patch applies cleanly against 0.28 - with current git master it applies with 'offset 1 line'.
The remaining issue is exit status of pkg-config when error during parsing of one of the .pc files - before it was '1' and after the patch applied it is '0'.
**Attachment 96614**, "Implement parser control logic in place of exit() when error occurs":
[add_flow_control_in_place_of_exits_for_list-all_command_to_work.patch](/uploads/698ac9a8c81d6e79dd540def62c1f605/add_flow_control_in_place_of_exits_for_list-all_command_to_work.patch)https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/31Execution of compiled pkg-config-0.28 on Synology DS712+ results in a Segment...2018-08-25T12:55:10ZBugzilla Migration UserExecution of compiled pkg-config-0.28 on Synology DS712+ results in a Segmentation fault (core dump)## Submitted by hdisseldorp
Assigned to **pkg..@..op.org**
**[Link to original bug (#78087)](https://bugs.freedesktop.org/show_bug.cgi?id=78087)**
## Description
After a successful creation of pkg-config-0.28. I get a segmentation...## Submitted by hdisseldorp
Assigned to **pkg..@..op.org**
**[Link to original bug (#78087)](https://bugs.freedesktop.org/show_bug.cgi?id=78087)**
## Description
After a successful creation of pkg-config-0.28. I get a segmentation fault when I try to execute the compiled program. Here are the steps I took to compile the program.
I have downloaded pkg-config-0.28.tar.gz into a local tmp directory.
I executed the following commands:
1) tar xvzf pkg-config-0.28.tar.gz
2) cd pkg-config-0.28
3) env LDFLAGS="-L/opt/lib" ./configure --prefix=/usr/local
4) make install
5) /usr/local/pkg-config --version
6) Segmentation fault (core dumped)
Al this is run on a Synology DS712+ NAS server on which I installed ipkg, to be able to install additional (development) packages. I guess that the segmentation fault is caused by linking with the wrong library (versions).
The reason I need an updated version of pkg-config is to be able to compile the latest ruby version. The current pkg-config version (0.15) don't recognize the "URL' tag.
Can somebody help me out with this problem?
Kind regards,
Harryhttps://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/9Unintuitive --version when a package is given2018-08-25T12:53:11ZBugzilla Migration UserUnintuitive --version when a package is given## Submitted by Bill Spitzak
Assigned to **pkg..@..op.org**
**[Link to original bug (#79024)](https://bugs.freedesktop.org/show_bug.cgi?id=79024)**
## Description
"pkg-config --version foo" should do one of the following:
1. Act ...## Submitted by Bill Spitzak
Assigned to **pkg..@..op.org**
**[Link to original bug (#79024)](https://bugs.freedesktop.org/show_bug.cgi?id=79024)**
## Description
"pkg-config --version foo" should do one of the following:
1. Act like "pkg-config --modversion foo"
2. Produce an error message. Bonus points if the error message contains "--modversion" in it.
Current behavior (of ignoring the "foo" and producing the version of pkg-config) is incredibly non-intuitive.