View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015804CMakeModulespublic2015-10-20 05:322016-06-10 14:31
ReporterSam Thursfield 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.3.2 
Target VersionFixed in Version 
Summary0015804: FindPkgConfig pkg_check_modules command should return full path to shared libraries in _LIBRARIES variable
DescriptionCMake seems to encourage using absolute paths to shared libraries.

From link_directories() documentation:

       Note that this command is rarely necessary. Library locations returned
       by find_package() and find_library() are absolute paths. Pass these
       absolute library file paths directly to the target_link_libraries()
       command. CMake will ensure the linker finds them.

However, the FindPkgConfig module doesn't follow this, and instead returns just the names of libraries, plus a linker path. Since CMake makes it awkward to propagate the linker path, so the end result is that if you have a package installed in a non-standard library path, things break.
Steps To ReproduceAn example pkg-config file:

  cmake_minimum_required(VERSION 3.3.2)

  find_package(PkgConfig REQUIRED)

  pkg_check_modules(ZLIB zlib REQUIRED)

  message("ZLIB_LIBRARIES: ${ZLIB_LIBRARIES}")
  message("ZLIB_LIBRARY_DIRS: ${ZLIB_LIBRARY_DIRS}")

Output:

  ZLIB_LIBRARIES: z
  ZLIB_LIBRARY_DIRS: /usr/lib64

Expected output:

  ZLIB_LIBRARIES: /usr/lib64/libz.so
Additional InformationI'm aware that in the case of Zlib there is a FindZLib module, and /usr/lib64 is in my library search path in any case. This is just an example. The painful case is where I had to build a library from source myself and then install it into a non-standard prefix.
TagsNo tags attached.
Attached Filespatch file icon cmake-pkg-config-absolute-paths.patch [^] (2,189 bytes) 2015-10-20 17:59 [Show Content]
patch file icon cmake-pkg-import-module.patch [^] (5,839 bytes) 2016-01-12 12:58 [Show Content]

 Relationships
related to 0015805closedBen Boeckel pkg_get_variable from FindPkgConfig should honour search path from CMAKE_PREFIX_PATH 

  Notes
(0039663)
Sam Thursfield (reporter)
2015-10-20 18:04

Attached is a patch to implement this behaviour.

I'm not sure if this can be merged without breaking backwards compatibility... it may need either a new policy, or a new variable to be used instead of changing the meaning of xx_LIBRARIES. (Maybe xx_LIBRARY_PATHS ?)

That said, I think other Findxx modules already return absolute paths in xx_LIBRARIES, and the only breakage I can imagine in practice would involve manually constructing a linker commandline from xx_LIBRARIES using ${CMAKE_LINK_LIBRARY_FLAG}... which seems quite broken already.

I'm happy to rework the patch, anyway.
(0039664)
Sam Thursfield (reporter)
2015-10-20 18:10

Some related bugs that could, I think, be closed if this was fixed:

https://cmake.org/Bug/view.php?id=14345 [^] (pkg_check_modules does not honor link command given by pkg-config: leaves out -L flag)
https://cmake.org/Bug/view.php?id=12317 [^] (pkg_check_modules produces output incompatible with other cmake variables)

and possibly:

https://cmake.org/Bug/view.php?id=8644 [^] (Imcompatible output of pkg_check_modules for flags)
(0039665)
Sam Thursfield (reporter)
2015-10-20 18:14

Just thought of another possible way to solve this -- FindPkgConfig could generate an imported target for the different modules, with the full library path set. It seems like this is the current "best practice" of referencing external libraries, and it would not interfere with existing operation. On the other hand, it would take a bit longer to implement, and all existing users would need to manually update their CMakeLists to get the new behaviour.

What would be the best approach?
(0039666)
Brad King (manager)
2015-10-21 08:27

IIRC the original intention of FindPkgConfig was just to report what pkg-config reports. Then the results can be used by other find modules to provide the actual _LIBRARIES variable, imported targets, etc.

We could provide this more complete functionality in a compatible way by providing a separate interface or option to enable it. It would be nice to be able to ask for an imported target encoding the results.

This design discussion is perhaps better held on the cmake dev mailing list.
(0040207)
Sam Thursfield (reporter)
2016-01-12 12:59

I've not had time to start a design discussion, but attached is a patch that shows how I have solved this locally.

It adds a pkg_import_module() command, which generates an imported target for a given pkg-config module.

The approach seems to work for us. The function currently only works for shared libraries, I'm sure how to allow the user to get imported static targets instead.
(0042863)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-10-20 05:32 Sam Thursfield New Issue
2015-10-20 17:59 Sam Thursfield File Added: cmake-pkg-config-absolute-paths.patch
2015-10-20 18:04 Sam Thursfield Note Added: 0039663
2015-10-20 18:10 Sam Thursfield Note Added: 0039664
2015-10-20 18:14 Sam Thursfield Note Added: 0039665
2015-10-21 08:27 Brad King Note Added: 0039666
2015-10-21 08:28 Brad King Relationship added related to 0015805
2016-01-12 12:58 Sam Thursfield File Added: cmake-pkg-import-module.patch
2016-01-12 12:59 Sam Thursfield Note Added: 0040207
2016-06-10 14:29 Kitware Robot Note Added: 0042863
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team