CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-01-14T14:21:13-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25588PIE link flags are not used when POSITION_INDEPENDENT_CODE is ON without chec...2024-01-14T14:21:13-05:00Mi-LaPIE link flags are not used when POSITION_INDEPENDENT_CODE is ON without check_pie_supported being called (CMP0083 is set to NEW)Documentation to [CMP0083](https://cmake.org/cmake/help/latest/policy/CMP0083.html) says that when it's set to NEW, POSITION_INDEPENDENT_CODE option should control usage of PIE link falgs (e.g. `-pie`, `-no-pie` on GCC). But when I set t...Documentation to [CMP0083](https://cmake.org/cmake/help/latest/policy/CMP0083.html) says that when it's set to NEW, POSITION_INDEPENDENT_CODE option should control usage of PIE link falgs (e.g. `-pie`, `-no-pie` on GCC). But when I set the `POSITION_INDEPENDENT_CODE` to `FALSE`, the `-no-pie` option is not added until I call the [`check_pie_supported`](https://cmake.org/cmake/help/latest/module/CheckPIESupported.html).
> Since a given linker may not support PIE flags in all environments in which it is used, it is the project's responsibility to use the CheckPIESupported module to check for support to ensure that the POSITION_INDEPENDENT_CODE target property for executables will be honored at link time.
From the doc I only understand that `check_pie_supported` is just a helper for users to be able to check whether the PIE flags are supported or not in the current environment. It's not clear that calling it will change the behavior.
```cmake
cmake_minimum_required(VERSION 3.14)
project(pie_test)
include(CheckPIESupported)
#check_pie_supported() # uncomment this line to add `-no-pie` to the link flags
add_executable(pie_test test.cpp)
set_property(TARGET pie_test PROPERTY POSITION_INDEPENDENT_CODE FALSE)
```
```cpp
int main() { return 0; }
```
Tested on Ubuntu 22.04, cmake version 3.22.1, gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0.
Note that issue https://gitlab.kitware.com/cmake/cmake/-/issues/18955 mentions in several comments - e.g. https://gitlab.kitware.com/cmake/cmake/-/issues/18955#note_520102 that `check_pie_supported` is required to be called.https://gitlab.kitware.com/cmake/cmake/-/issues/17377pkg config module does not search default paths when --libs returns -L....2020-02-25T15:29:43-05:00Charlie Bartopkg config module does not search default paths when --libs returns -L....if a pkg config file returns a linker args string with -L in it then cmake will ONLY search along that path. So for example if I have liblcm which links against glib2.0 and I install lcm in /usr/local, cmake will (silently!) produce the ...if a pkg config file returns a linker args string with -L in it then cmake will ONLY search along that path. So for example if I have liblcm which links against glib2.0 and I install lcm in /usr/local, cmake will (silently!) produce the wrong output. Not only does it not find glib but it does not even add lcm to the linker command line in this case.
It's not super clear how this should be fixed but imo what happens now is definitely wronghttps://gitlab.kitware.com/cmake/cmake/-/issues/23630pkg-config finds incomaptible libs2022-06-16T10:59:33-04:00Fabian Keßlerpkg-config finds incomaptible libsIf I have 2 libraries, one build via msvc and one build by Msys2 / mingw64. "pkg-config" will always find the library which occurs first in the search path. Since the libs are not compatible between each compiler types, they should not t...If I have 2 libraries, one build via msvc and one build by Msys2 / mingw64. "pkg-config" will always find the library which occurs first in the search path. Since the libs are not compatible between each compiler types, they should not to be considered as found or the search should continue when they are actually incompatible to the current tool chain.https://gitlab.kitware.com/cmake/cmake/-/issues/23632pkg_check_modules creates broken targets for msvc2022-11-18T18:49:02-05:00Fabian Keßlerpkg_check_modules creates broken targets for msvcusing pkg_check_modules to find imported targets may result in targets containing libraries without its path for msvc:
For example, having the glib.pc down here <XXX>_LINK_LIBRARIES only lists `glib-2.0 intl` without their path.
glib.p...using pkg_check_modules to find imported targets may result in targets containing libraries without its path for msvc:
For example, having the glib.pc down here <XXX>_LINK_LIBRARIES only lists `glib-2.0 intl` without their path.
glib.pc:
```
prefix=C:/gtk-build/gtk/x64/release
includedir=${prefix}/include
libdir=${prefix}/lib
bindir=${prefix}/bin
glib_genmarshal=${bindir}/glib-genmarshal
gobject_query=${bindir}/gobject-query
glib_mkenums=${bindir}/glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.72.2
Libs: -L${libdir} -lglib-2.0 -lintl
Libs.private: -lws2_32 -lwinmm
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
```
Another example for GTK3:
```
[cmake] -- GTK3_LINK_LIBRARIES: gtk-3;gdk-3;C:/Windows/System32/gdi32.dll;C:/Windows/System32/imm32.dll;C:/Windows/System32/shell32.dll;C:/Windows/System32/ole32.dll;C:/Windows/System32/winmm.dll;C:/Windows/System32/dwmapi.dll;C:/Windows/System32/setupapi.dll;C:/Windows/System32/cfgmgr32.dll;C:/Windows/System32/hid.dll;winspool;C:/Windows/System32/comctl32.dll;C:/Windows/System32/comdlg32.dll;pangowin32-1.0;pangocairo-1.0;pango-1.0;P:/vcpkg/installed/x64-windows/debug/bin/harfbuzz.dll;atk-1.0;cairo-gobject;cairo;gio-2.0;gdk_pixbuf-2.0;gobject-2.0;glib-2.0;intl
[cmake] -- GTK3_LIBRARIES = gtk-3;gdk-3;gdi32;imm32;shell32;ole32;winmm;dwmapi;setupapi;cfgmgr32;hid;winspool;comctl32;comdlg32;pangowin32-1.0;pangocairo-1.0;pango-1.0;harfbuzz;atk-1.0;cairo-gobject;cairo;gio-2.0;gdk_pixbuf-2.0;gobject-2.0;glib-2.0;intl
[cmake] -- GTK3_LIBRARY_DIRS = C:/gtk-build/gtk/x64/release/lib
```
Note, that GTK3_LIBRARY_DIRS is not in the path, so the linker is unable to find those.https://gitlab.kitware.com/cmake/cmake/-/issues/17945pkg_check_modules does not add frameworks to libraries variable2018-05-11T10:39:15-04:00Daniel Oberhoffpkg_check_modules does not add frameworks to libraries variablefor example when using ffmpeg master i have
$ pkg-config --libs libavutil
-L/opt/ffmpeg-master//lib -lavutil -pthread -lm -framework VideoToolbox -framework CoreFoundation -framework CoreMedia -framework CoreVideo -framework CoreService...for example when using ffmpeg master i have
$ pkg-config --libs libavutil
-L/opt/ffmpeg-master//lib -lavutil -pthread -lm -framework VideoToolbox -framework CoreFoundation -framework CoreMedia -framework CoreVideo -framework CoreServices
but the libraries variable only parses the -l arguments, not the -framework <framework> oneshttps://gitlab.kitware.com/cmake/cmake/-/issues/14345pkg_check_modules does not honor link command given by pkg-config: leaves out...2020-03-05T18:29:49-05:00Kitware Robotpkg_check_modules does not honor link command given by pkg-config: leaves out -L flagThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14345). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14345). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17886pkg_check_modules does not parse the pkg-config -cflags correctly when there ...2018-04-10T12:51:35-04:00Kamanashis Roy Shuvapkg_check_modules does not parse the pkg-config -cflags correctly when there is preprocessorIn scenario when the `foo.pc` file looks like the following,
```
Name: foo
Version: 1.0.0
Libs: -lfoo
Cflags: -IFoo/includes -DSPECIFICATION=" ABCD4 "
```
The `pkg-config --cflags foo` command gives the following,
```
-DSPECIFICATION=...In scenario when the `foo.pc` file looks like the following,
```
Name: foo
Version: 1.0.0
Libs: -lfoo
Cflags: -IFoo/includes -DSPECIFICATION=" ABCD4 "
```
The `pkg-config --cflags foo` command gives the following,
```
-DSPECIFICATION=\ ABCD4 -IFoo/includes
```
But when used with pkg_check_modules(FOO foo), it gets,
```
FOO_CFLAGS_OTHER = -D;SPECIFICATION=;ABCD4
```
And it becomes ,
```
/usr/bin/c++ -IFoo/Inc -D SPECIFICATION= ABCD4 -o xxxfoo.cc.o -c foo.cc
```
And finally the compiler cannot find the file named ABCD4.https://gitlab.kitware.com/cmake/cmake/-/issues/18150pkg_check_modules does not respect CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH an...2021-11-03T19:12:57-04:00Boian Petkantchinpkg_check_modules does not respect CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATHI am trying to find a specific version of ffmpeg in non-default location.
I have.
```CMake
find_package(PkgConfig REQUIRED)
set(PKG_CONFIG_USE_CMAKE_PREFIX_PATH ON)
list(APPEND CMAKE_PREFIX_PATH "${ffmpeg_INSTALL_DIR}/lib/pkgconfig")
li...I am trying to find a specific version of ffmpeg in non-default location.
I have.
```CMake
find_package(PkgConfig REQUIRED)
set(PKG_CONFIG_USE_CMAKE_PREFIX_PATH ON)
list(APPEND CMAKE_PREFIX_PATH "${ffmpeg_INSTALL_DIR}/lib/pkgconfig")
list(APPEND CMAKE_FRAMEWORK_PATH "${ffmpeg_INSTALL_DIR}/lib/pkgconfig")
list(APPEND CMAKE_APPBUNDLE_PATH "${ffmpeg_INSTALL_DIR}/lib/pkgconfig")
pkg_check_modules(ffmpeg REQUIRED libavcodec>=57.107.100 libavutil>=55.78.100 libswresample>=2.9.100)
```
This fails to find the libs.
On the other hand this works.
```CMake
find_package(PkgConfig REQUIRED)
set(ENV{PKG_CONFIG_PATH} "$ENV{PKG_CONFIG_PATH}:${ffmpeg_INSTALL_DIR}/lib/pkgconfig")
pkg_check_modules(ffmpeg REQUIRED libavcodec>=57.107.100 libavutil>=55.78.100 libswresample>=2.9.100)
```
Tried it with CMake version 3.5.1.https://gitlab.kitware.com/cmake/cmake/-/issues/25692pkg_check_modules fails on unmet Requires.private pkg-config requirement2024-02-20T20:55:09-05:00apteryxpkg_check_modules fails on unmet Requires.private pkg-config requirementHello,
While improving the pkg-config file of autotrace as shown here: https://github.com/autotrace/autotrace/blob/8d7c8085c63df41f73f0e4c2c3893d33d03f5755/autotrace.pc.in, it came to my attention that a CMake `pkg_check_modules(INKSCAP...Hello,
While improving the pkg-config file of autotrace as shown here: https://github.com/autotrace/autotrace/blob/8d7c8085c63df41f73f0e4c2c3893d33d03f5755/autotrace.pc.in, it came to my attention that a CMake `pkg_check_modules(INKSCAPE_DEP autotrace)` fails when `pstoedit` is not provided in the environment, due to the FindPkgConfig.cmake module making two calls to pkg-config, one being with `--static` causing the problem.
This should not be fatal as I'm building a shared library and don't need the `Requires.private` pkg-config packages in the environment, since the libautotrace.so library already captured these in its binary ELF file (as NEEDED dependencies, with the correct RUNPATH search path).
Here's what it looks like, in an environment containing autotrace but not its transitive dependencies (such as pstoedit), using the following sample CMakeLists.txt:
```
project(dummy)
cmake_minimum_required(VERSION 3.24)
find_package(PkgConfig REQUIRED)
pkg_check_modules(INKSCAPE_DEP REQUIRED autotrace)
```
Using the freedesktop `pkg-config`:
```
$ cmake --fresh .
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /gnu/store/1pjxm4facm1xhpqad9b7zzcz789j01qq-profile/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /gnu/store/1pjxm4facm1xhpqad9b7zzcz789j01qq-profile/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /gnu/store/1pjxm4facm1xhpqad9b7zzcz789j01qq-profile/bin/pkg-config (found version "0.29.2")
-- Checking for module 'autotrace'
-- Package 'pstoedit', required by 'autotrace', not found
CMake Error at /gnu/store/1fzd3ak386lgv7zl28j7zqkviv8wkz8d-cmake-minimal-3.24.2/share/cmake-3.24/Modules/FindPkgConfig.cmake:607 (message):
A required package was not found
Call Stack (most recent call first):
/gnu/store/1fzd3ak386lgv7zl28j7zqkviv8wkz8d-cmake-minimal-3.24.2/share/cmake-3.24/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal)
CMakeLists.txt:4 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
See also "/tmp/guix-build-inkscape-1.3.2.drv-0/build2/CMakeFiles/CMakeOutput.log".
$ echo $?
1
```
Using `pkgconf` as pkg-config (symlink):
```
$ cmake --fresh .
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /gnu/store/hbcrngynpzraz9ciqq12wj6abip4s3rn-profile/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /gnu/store/hbcrngynpzraz9ciqq12wj6abip4s3rn-profile/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /gnu/store/hbcrngynpzraz9ciqq12wj6abip4s3rn-profile/bin/pkg-config (found version "2.1.0")
-- Checking for module 'autotrace'
-- Found autotrace, version 0.40.0
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
Package pstoedit was not found in the pkg-config search path.
Perhaps you should add the directory containing `pstoedit.pc'
to the PKG_CONFIG_PATH environment variable
Package 'pstoedit', required by 'autotrace', not found
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/guix-build-inkscape-1.3.2.drv-0/build2
$ echo $?
0
```
```
$ pkg-config --version
0.29.2
$ pkg-config --short-errors --print-errors --exists --static autotrace
Package 'pstoedit', required by 'autotrace', not found
$ echo $?
1
$ pkgconf --version
2.1.0
$ pkgconf --short-errors --print-errors --exists --static autotrace
Package 'pstoedit', required by 'autotrace', not found
$ echo $?
1
```https://gitlab.kitware.com/cmake/cmake/-/issues/15795pkg_check_modules produces incorrect results depending on contents of CMakeCa...2024-03-05T09:46:33-05:00Kitware Robotpkg_check_modules produces incorrect results depending on contents of CMakeCache.txtThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15795). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15795). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17089pkg_check_modules with "::" in prefix2017-10-12T13:04:10-04:00chuck cranorpkg_check_modules with "::" in prefixI have a CMakeLists.txt statement that works with cmake 2.8.12.2 and 3.7.2
but fails with 3.9.0:
<pre>
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
I get error "syntax error, unexpected cal_SYMBOL, expecting } (36)"
I'm no...I have a CMakeLists.txt statement that works with cmake 2.8.12.2 and 3.7.2
but fails with 3.9.0:
<pre>
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
I get error "syntax error, unexpected cal_SYMBOL, expecting } (36)"
I'm not getting any backward compat warnings, so I wonder if it should work
with 3.9.0?
My coworker says he is also seeing the error with 3.8.2.
I made a simple test for this:
<pre>
cmake_minimum_required (VERSION 2.8.12)
project (TEST)
find_package(PkgConfig REQUIRED)
pkg_check_modules ("glog::glog" REQUIRED libglog)
</pre>
Here is some sample output for the 3 cmake versions noted above:
<pre>
chuck@h0:/tmp/test/b % cat ../CMakeLists.txt
cmake_minimum_required (VERSION 2.8.12)
project (TEST)
find_package(PkgConfig REQUIRED)
pkg_check_modules ("glog::glog" REQUIRED libglog)
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % cmake --version
cmake version 3.9.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).
chuck@h0:/tmp/test/b % cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
CMake Error at /tmp/cmake/share/cmake-3.9/Modules/FindPkgConfig.cmake:587 (if):
Syntax error in cmake code at
/tmp/cmake/share/cmake-3.9/Modules/FindPkgConfig.cmake:587
when parsing string
${__pkg_config_arguments_glog::glog}
syntax error, unexpected cal_SYMBOL, expecting } (36)
Call Stack (most recent call first):
CMakeLists.txt:4 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
See also "/tmp/test/b/CMakeFiles/CMakeOutput.log".
chuck@h0:/tmp/test/b % rm -rf *
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % /usr/bin/cmake --version
cmake version 2.8.12.2
chuck@h0:/tmp/test/b % /usr/bin/cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'libglog'
-- found libglog, version 0.3.3
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/b
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % rm -rf *
chuck@h0:/tmp/test/b %
chuck@h0:/tmp/test/b % /proj/TableFS/data/travis14/cache/bin/cmake --version
cmake version 3.7.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
chuck@h0:/tmp/test/b % /proj/TableFS/data/travis14/cache/bin/cmake ..
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libglog'
-- Found libglog, version 0.3.3
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/test/b
chuck@h0:/tmp/test/b %
</pre>https://gitlab.kitware.com/cmake/cmake/-/issues/25587pkg_check_modules: handle space-joined linker flags2024-01-15T10:48:10-05:00Someonepkg_check_modules: handle space-joined linker flags<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
Following up on https://discourse.cmake.org/t/issues-with-opmi-cxx-pc-s-ldflags-and-pkg-check-modules-imported-target/9651 and https://github.com/open-mpi/ompi/issues/12194, `pkg_check_modules(... IMPORTED_TARGET ...)` may discard significant `-Wl` flags present in the `.pc` file, presumably in its dedup phase.
E.g.
```console
❯ cat /nix/store/radkdwgnz90jx0fjssajsikjymp631cb-openmpi-4.1.6/lib/pkgconfig/ompi-cxx.pc
# ...
Libs: -L${libdir} -L/nix/store/iyzz6m4dr6grn10qi67a1g1lp3wrnk7j-libfabric-1.20.0-dev/lib -L/nix/store/bfk76ihs1whd9l51pq1s93sn0j2zd6zq-pmix-5.0.1/lib -L/nix/store/bdd88wiwfzyi7fh04f04y05y7kh1ycz0-libnl-3.7.0-dev/lib -L/nix/store/c8byxr5hgiqyf69d3jr51wgi7g420xsl-libpsm2-12.0.1/lib -Wl,-rpath -Wl,${libdir} -Wl,-rpath -Wl,/nix/store/iyzz6m4dr6grn10qi67a1g1lp3wrnk7j-libfabric-1.20.0-dev/lib -Wl,-rpath -Wl,/nix/store/bfk76ihs1whd9l51pq1s93sn0j2zd6zq-pmix-5.0.1/lib -Wl,-rpath -Wl,/nix/store/bdd88wiwfzyi7fh04f04y05y7kh1ycz0-libnl-3.7.0-dev/lib -Wl,-rpath -Wl,/nix/store/c8byxr5hgiqyf69d3jr51wgi7g420xsl-libpsm2-12.0.1/lib -Wl,--enable-new-dtags -lmpi_cxx -lmpi
Libs.private: -lopen-rte -lopen-pal -lhwloc -lfabric -lucp -luct -lucm -lucs -libverbs -lrdmacm -levent_core -levent_pthreads -lpmix -lnl-3 -lnl-route-3 -lucc -lpsm2 -lm -lz
#
Cflags: -I${includedir}
```
...translates into
```
3jr51wgi7g420xsl-libpsm2-12.0.1/lib;-Wl,--enable-new-dtags;-lmpi_cxx;-lmpi
samples> MPI_CXX_LDFLAGS_OTHER=-Wl,-rpath;-Wl,/nix/store/radkdwgnz90jx0fjssajsikjymp631cb-openmpi-4.1.6/lib;-Wl,-rpath;-Wl,/nix/store/iyzz6m4dr6grn10qi67a1g1lp3wrnk7j-libfabric-1.20.0-dev/lib;-Wl,-rpath;-Wl,/nix/store/bfk76ihs1whd9l51pq
1s93sn0j2zd6zq-pmix-5.0.1/lib;-Wl,-rpath;-Wl,/nix/store/bdd88wiwfzyi7fh04f04y05y7kh1ycz0-libnl-3.7.0-dev/lib;-Wl,-rpath;-Wl,/nix/store/c8byxr5hgiqyf69d3jr51wgi7g420xsl-libpsm2-12.0.1/lib;-Wl,--enable-new-dtags
samples> MPI_CXX_LIBRARIES=mpi_cxx;mpi
...
samples> /nix/store/sfgnb6rr428bssyrs54d6d0vv2avi95c-gcc-wrapper-12.3.0/bin/g++ -O3 -DNDEBUG -Wl,-rpath -Wl,/nix/store/radkdwgnz90jx0fjssajsikjymp631cb-openmpi-4.1.6/lib -Wl,/nix/store/iyzz6m4dr6grn10qi67a1g1lp3wrnk7j-libfabric-1.20.0-dev/lib -Wl,/nix/store/bfk76ihs1whd9l51pq1s93sn0j2zd6zq-pmix-5.0.1/lib -Wl,/nix/store/bdd88wiwfzyi7fh04f04y05y7kh1ycz0-libnl-3.7.0-dev/lib -Wl,/nix/store/c8byxr5hgiqyf69d3jr51wgi7g420xsl-libpsm2-12.0.1/lib -Wl,--enable-new-dtags CMakeFiles/roundtrip.dir/exercise_sheets/sheet3/time.cc.o -o roundtrip /nix/store/radkdwgnz90jx0fjssajsikjymp631cb-openmpi-4.1.6/lib/libmpi_cxx.so /nix/store/radkdwgnz90jx0fjssajsikjymp631cb-openmpi-4.1.6/lib/libmpi.so
samples> /nix/store/fzlkaj1ax7gl655blfcr6zzvml1vx3bj-binutils-2.40/bin/ld: error: /nix/store/iyzz6m4dr6grn10qi67a1g1lp3wrnk7j-libfabric-1.20.0-dev/lib: read: Is a directory
samples> collect2: error: ld returned 1 exit status
```
Note how all but the first `-Wl,-rpath` are omitted. While it is possible to rewrite the `.pc` files (in this case generated by libtool) in a simpler format (`-Wl,-rpath,...`, `-Wl,-rpath,=`), CMake in this situation is arguably misinterpreting otherwise valid arguments.
Would you consider supporting this special case? Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/20215pkg_get_variable (defined in FindPkgConfig.cmake) fails to honour CMAKE_PREFI...2020-01-29T16:50:54-05:00Alan W. Irwinpkg_get_variable (defined in FindPkgConfig.cmake) fails to honour CMAKE_PREFIX_PATHPLplot links to libLASi. The libLASi package uses a pkg-config approach to publish information about that
package so PLplot uses FindPkgConfig.cmake (all current tests are for CMake-3.13.4, if that makes any difference) to configure ho...PLplot links to libLASi. The libLASi package uses a pkg-config approach to publish information about that
package so PLplot uses FindPkgConfig.cmake (all current tests are for CMake-3.13.4, if that makes any difference) to configure how it builds against libLASi. I had been testing a locally installed (in /home/software/lasi_svn/install) version of libLASi without issues using env ... CMAKE_PREFIX_PATH=...:/home/software/lasi_svn/install:...
However, just now I attempted to obtain an extra variable from that lasi.pc file using pkg_get_variable, and that failed to work with the above CMAKE_PREFIX_PATH. To work around that inconsistency with how CMAKE_PREFIX_PATH is honoured within FindPkgConfig.cmake, I replaced the above CMAKE_PREFIX_PATH approach with PKG_CONFIG_PATH=/home/software/lasi_svn/install/lib/pkgconfig, and all was well. So that is a reasonable workaround. Nevertheless, it "would be nice" if this inconsistency in how CMAKE_PREFIX_PATH is honoured within FindPkgConfig.cmake was fixed.https://gitlab.kitware.com/cmake/cmake/-/issues/23260pkg_get_variable difference between pkg-config 0.27 and 0.292022-02-24T04:08:01-05:00Florian Apollonerpkg_get_variable difference between pkg-config 0.27 and 0.29Hi there,
when trying `FindCURL` I noticed that the components search does not work. Interestingly enough it worked on another system. Digging deeper I found this commit https://github.com/freedesktop/pkg-config/commit/50c2867f4a6981e08...Hi there,
when trying `FindCURL` I noticed that the components search does not work. Interestingly enough it worked on another system. Digging deeper I found this commit https://github.com/freedesktop/pkg-config/commit/50c2867f4a6981e085c721d936c96f174f11f415 which is part of pkg-config 0.29.1 and unquotes variables.
So with pkg-config 0.27 (shipped with CentOS 7) I get:
```
pkg-config --variable=supported_protocols libcurl
"HTTP HTTPS MQTT"
```
which in pkg_get_variable results in `['"HTTP', 'HTTPS', 'MQTT"']`
and with pkg-config 0.29 I get:
```
pkg-config --variable=supported_protocols libcurl
HTTP HTTPS MQTT
```
which in pkg_get_variable results in `['HTTP', 'HTTPS', 'MQTT']` -- which allows `FindCURL` to actually find the HTTP component.
Is there anything CMake can do? Is there any workaround I could apply short of upgrading pkg-config?https://gitlab.kitware.com/cmake/cmake/-/issues/19232pkg_get_variable does not work for packages not in /usr/lib/pkgconfig2020-02-19T08:53:31-05:00Tarun Prabhupkg_get_variable does not work for packages not in /usr/lib/pkgconfigpkg_get_variable does not correctly return a result when the .pc file for a package is not in /usr/lib/pkgconfig. If the .pc file is copied to /usr/lib/pkgconfig, the variable's value is returned correctly.pkg_get_variable does not correctly return a result when the .pc file for a package is not in /usr/lib/pkgconfig. If the .pc file is copied to /usr/lib/pkgconfig, the variable's value is returned correctly.https://gitlab.kitware.com/cmake/cmake/-/issues/24818PkgConfig IMPORT_TARGET not working as intended for MSVC pkg-config files2023-04-25T15:25:49-04:00Bharatvajbharatvaj@yahoo.comPkgConfig IMPORT_TARGET not working as intended for MSVC pkg-config files```
CMake Error in CMakeLists.txt:
Imported target "PkgConfig::SKIA" includes non-existent path
"/IC:/Users/Administrator/test-project/out/.sysroot/x86_64-pc-windows-msvc/include/skia"
in its INTERFACE_INCLUDE_DIRECTORIES. Pos...```
CMake Error in CMakeLists.txt:
Imported target "PkgConfig::SKIA" includes non-existent path
"/IC:/Users/Administrator/test-project/out/.sysroot/x86_64-pc-windows-msvc/include/skia"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
```
```
# CMakeLists.txt
if(MSVC)
set(PKG_CONFIG_ARGN "--msvc-syntax")
endif()
find_package(PkgConfig REQUIRED)
pkg_check_modules(SKIA REQUIRED IMPORTED_TARGET GLOBAL skia=109)
add_executable(test-project test-project.cpp)
target_link_libraries(test-project PUBLIC PkgConfig::SKIA)
```
The skia.pc file
```
prefix=${pcfiledir}/../..
libdir=${prefix}/lib
includedir=${prefix}/include/skia
Name: skia
Description: Skia is a complete 2D graphic library for drawing Text, Geometries, and Images.
Cflags: -I${includedir} -DSK_HAS_ANDROID_CODEC -DSKSL_ENABLE_TRACING -DSK_ENABLE_SPIRV_VALIDATION -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -DWIN32_LEAN_AND_MEAN -DNOMINMAX -DSK_ENABLE_SKSL -DSK_ENABLE_PRECOMPILE -DSK_GAMMA_APPLY_TO_A8 -DSK_ALLOW_STATIC_GLOBAL_INITIALIZERS=1 -DGR_TEST_UTILS=1 -DSKIA_IMPLEMENTATION=1 -DSK_DIRECT3D -DSK_ENABLE_D3D_DEBUG_LAYER -DSK_ENABLE_DUMP_GPU -DSK_SUPPORT_GPU=1 -DSK_ENABLE_SPIRV_CROSS -DSK_SUPPORT_PDF -DSK_CODEC_DECODES_JPEG -DSK_ENCODE_JPEG -DSK_SUPPORT_XPS -DSK_HAS_HEIF_LIBRARY -DSK_CODEC_DECODES_PNG -DSK_ENCODE_PNG -DSKVM_JIT_WHEN_POSSIBLE -DSK_CODEC_DECODES_WEBP -DSK_ENCODE_WEBP -DSK_HAS_WUFFS_LIBRARY -DSK_XML
Libs: /LIBPATH:${libdir} skia.lib
Libs.private: /LIBPATH:${libdir} DXGI.lib
Version: 109
```
Seems like cmake is not segregating the /I returned from pkg-config? I can confirm that the path "C:/Users/Administrator/test-project/out/.sysroot/x86_64-pc-windows-msvc/include/skia" exists in disk.https://gitlab.kitware.com/cmake/cmake/-/issues/20136PkgConfig::<prefix> targets don't respect the value of BUILD_SHARED_LIBS2022-04-06T13:52:29-04:00tobimPkgConfig::<prefix> targets don't respect the value of BUILD_SHARED_LIBSThe targets defined after calls to `pkg_check_modules` have their `INTERFACE_LINK_LIBRARIES` populated from `${_prefix}_LINK_LIBRARIES`. If the pkg-config file contains a non-empty `Requires.private` field that property is incorrect for ...The targets defined after calls to `pkg_check_modules` have their `INTERFACE_LINK_LIBRARIES` populated from `${_prefix}_LINK_LIBRARIES`. If the pkg-config file contains a non-empty `Requires.private` field that property is incorrect for static builds.
There are of course various ways to work around that but all of those induce overhead on the user.
It would be nice if the definition of `_pkg_create_imp_target` could be extended to respect `BUILD_SHARED_LIBS`.https://gitlab.kitware.com/cmake/cmake/-/issues/14753Place CMAKE_CXX_FLAGS_DEBUG before CMAKE_CXX_FLAGS, not after (for all simila...2017-10-13T13:17:56-04:00Kitware RobotPlace CMAKE_CXX_FLAGS_DEBUG before CMAKE_CXX_FLAGS, not after (for all similar flags)This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14753). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14753). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17962Please add configure time expandable expressions2018-07-05T07:36:30-04:00Eugene ShalyginPlease add configure time expandable expressionsGenerator expressions allow to greatly simplify conditional statements, but obviously work at the generation phase. The lack of return values in the CMake language result in prolix code, unneeded temporal variables, etc. Could you, pleas...Generator expressions allow to greatly simplify conditional statements, but obviously work at the generation phase. The lack of return values in the CMake language result in prolix code, unneeded temporal variables, etc. Could you, please, consider adding "configuration expressions", similar to the generator ones? They might look in the very same way like the generator expressions but use another type of braces (e.g. $[]). Unlike a generator expression, a "configuration expression" is expanded as soon as encountered. A few examples follow.
`add_library(theLib $[IF:BUILD_PLUGINS,MODULE,STATIC])`
`target_sources(aTarget $[TRANSFORM:${srcs},PREPEND,src/) # add source files from the "src" subdir`
`if(${PackageName}_FOUND OR $[TOUPPER:${PackageName}]_FOUND)`
`target_link_libraries(aTarget PRIVATE
$[$[BOOL:WIN32]:wsock32 ws2_32 Iphlpapi]
$[$[BOOL:ANDROID]:${CMAKE_DL_LIBS}]
)`
`target_compile_options(aTarget PRIVATE
$[IF:CMAKE_COMPILER_ID MATCHES Clang:-Weverything,]
$[IF:CMAKE_COMPILER_ID MATCHES GNU:-Wall,]
$[IF:CMAKE_COMPILER_ID MATCHES MSVC:/W4,]
)`
And a bit from the dark side:
`$[EVAL:variableName,list(JOIN ${aList} "blah-blah" variableName)]` expands to `${variableName}` after evaluating the given expression in the current contexthttps://gitlab.kitware.com/cmake/cmake/-/issues/5847please create "cmake -E install" command2018-04-28T09:16:28-04:00Kitware Robotplease create "cmake -E install" commandThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=5847). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=5847). Further discussion may take place here.