Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: correct way to use Requires.private #300

Closed
freeekanayaka opened this issue Jun 20, 2023 · 4 comments
Closed

Question: correct way to use Requires.private #300

freeekanayaka opened this issue Jun 20, 2023 · 4 comments

Comments

@freeekanayaka
Copy link

Hi,

I'm trying to understand how to correctly use the Requires.private property in a .pc file.

Let's say that libA internally depends on libB and that libA.so is dynamically linked to libB.so when libA is built as shared library.

My understanding is that libA should include libB in its Requires.private .pc file, is that right?

That would be mainly in order to support static builds.

Now, let's say that my-app is using libA and uses PKG_CHECK_MODULES in its configure.ac to detect the presence of libA. As far as I can see if Requires.private is used, the configure script of my-app will fail with something:

configure: error: Package requirements (libA >= 0.0.1) were not met:

Package 'libB', required by 'libA', not found

if the .pc file of libB is not installed on the system. This happens because the pkg.m4 macros generates a command like:

/usr/bin/pkg-config --cflags "libA >= 0.0.1"

which fails with:

Package libB was not found in the pkg-config search path.
Perhaps you should add the directory containing `libB.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libB', required by 'libA', not found

Distributions like Debian ship .pc files in a separate -dev package, so the scenario in which the .pc file of libA is present, but the one of libB is not is actually the normal one, because a user building my-app should only need the the libA-dev package.

Should perhaps Libs.private be used instead? I'm confused about the proper way to do this.

Thanks

@kaniini
Copy link
Member

kaniini commented Jun 29, 2023

Requires.private is always considered for CFLAGS, because the module's headers may be referenced by the dependent (in fact, this would make a lot of sense, consider a module which builds on top of GTK, for example, it would need to reference the GTK headers).

Requires.private is only considered for LIBS if --static is also requested.

@freeekanayaka
Copy link
Author

Requires.private is always considered for CFLAGS, because the module's headers may be referenced by the dependent (in fact, this would make a lot of sense, consider a module which builds on top of GTK, for example, it would need to reference the GTK headers).

Requires.private is only considered for LIBS if --static is also requested.

Thanks for your reply, I had missed it and I'm only reading it now. What if the modules headers are not referenced by the dependent? Is there a way to have CFLAGS behave in the same way as LIBS? I.e. make Requires.private only considered if --static is requested, both for LIBS and CFLAGS.

@floppym
Copy link

floppym commented Aug 22, 2023

ppisar added a commit to ppisar/librepo that referenced this issue Apr 8, 2024
…abled

If librepo is built with zchunk support, zchunk's zck.h header file is
included from librepo public header files, thus applications building
against librepo needs zchunk header files available at build time.
Those who only use pkg-config for tracking dependencies, reported
build failures:

    /usr/include/librepo/downloadtarget.h:27:10: fatal error: zck.h: No such file or directory

This patch adds the dependency on zck to librepo.pc.

It enhances Requires.private instead of Requires to prevent from
contaminating "pkgconf --libs librepo" with -lzck. Contrary, "pkgconf
--cflags librepo" correctly appends include path to zck header files.
The dependency on zck.pc is only checked and enforced with "pkgconf
--cflags librepo" invocation. This behaviour is a feature. See
<pkgconf/pkgconf#352> and
<pkgconf/pkgconf#300>.

Fixes: rpm-software-management#305
ppisar added a commit to ppisar/pkgconf that referenced this issue Apr 8, 2024
Document that "pkgconf --cflags" inherits paths for including headers
from dependencies listed in Requires.private.

pkgconf#300
pkgconf#352
ppisar added a commit to ppisar/pkgconf that referenced this issue Apr 8, 2024
Document that "pkgconf --cflags" inherits paths for including headers
from dependencies listed in Requires.private.

pkgconf#300
pkgconf#352
ppisar added a commit to ppisar/librepo that referenced this issue Apr 11, 2024
…abled

If librepo is built with zchunk support, zchunk's zck.h header file is
included from librepo public header files, thus applications building
against librepo needs zchunk header files available at build time.
Those who only use pkg-config for tracking dependencies, reported
build failures:

    /usr/include/librepo/downloadtarget.h:27:10: fatal error: zck.h: No such file or directory

This patch adds the dependency on zck to librepo.pc.

It enhances Requires.private instead of Requires to prevent from
contaminating "pkgconf --libs librepo" with -lzck. Contrary, "pkgconf
--cflags librepo" correctly appends include path to zck header files.
The dependency on zck.pc is only checked and enforced with "pkgconf
--cflags librepo" invocation. This behaviour is a feature. See
<pkgconf/pkgconf#352> and
<pkgconf/pkgconf#300>.

Fixes: rpm-software-management#305
kontura pushed a commit to rpm-software-management/librepo that referenced this issue Apr 15, 2024
…abled

If librepo is built with zchunk support, zchunk's zck.h header file is
included from librepo public header files, thus applications building
against librepo needs zchunk header files available at build time.
Those who only use pkg-config for tracking dependencies, reported
build failures:

    /usr/include/librepo/downloadtarget.h:27:10: fatal error: zck.h: No such file or directory

This patch adds the dependency on zck to librepo.pc.

It enhances Requires.private instead of Requires to prevent from
contaminating "pkgconf --libs librepo" with -lzck. Contrary, "pkgconf
--cflags librepo" correctly appends include path to zck header files.
The dependency on zck.pc is only checked and enforced with "pkgconf
--cflags librepo" invocation. This behaviour is a feature. See
<pkgconf/pkgconf#352> and
<pkgconf/pkgconf#300>.

Fixes: #305
kaniini pushed a commit that referenced this issue Apr 26, 2024
Document that "pkgconf --cflags" inherits paths for including headers
from dependencies listed in Requires.private.

#300
#352
@kaniini
Copy link
Member

kaniini commented Apr 26, 2024

Documentation clarifying the current situation was merged in #353.

@kaniini kaniini closed this as completed Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants