Bug 1258742 - Libs.private interpreted in a wrong way
Libs.private interpreted in a wrong way
Product: Fedora
Classification: Fedora
Component: pkgconfig (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-09-01 03:39 EDT by Vratislav Podzimek
Modified: 2015-09-01 03:51 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-01 03:51:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vratislav Podzimek 2015-09-01 03:39:05 EDT
Description of problem:
The "Libs.private" field in the .pc files is interpreted by the pkg-config tool in a different way than what's described in the man pages.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. have a .pc file e.g. with 'Libs.private: -lrt'
2. try to build something requiring that package

Actual results:
Package 'librt', required by SOME_PACKAGE, not found

Expected results:
Only the librt.so file being checked/searched for as 'man pkg-config' describes:

              This  line  should  list  any private libraries in use.  Private libraries are libraries which are not exposed through your library, but are needed in the case of static linking. This differs
              from Requires.private in that it references libraries that do not have package files installed.

and also in the metadata file syntax description:
       Libs.private: -lm

Additional info:
an example of the above issue is current 'devmapper.pc' file
Comment 1 Vratislav Podzimek 2015-09-01 03:51:27 EDT
Turns out this was caused by a bug in device-mapper-devel the devmapper.pc file of which had 'librt' in 'Requires.private' and not in 'Libs.private'. I checked the file from last Rawhide build in Koji, but an older rawhide package was installed in our testing infrastructure hitting the issue described in this report.

Thus I'm closing this bug as WORKSFORME, sorry for the noise.

Note You need to log in before you can comment on or make changes to this bug.