guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg-config "Requires" fields and propagated inputs


From: Ludovic Courtès
Subject: Re: pkg-config "Requires" fields and propagated inputs
Date: Tue, 24 Mar 2015 21:57:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:

> If I'm reading pkg-config documentation[0] right, Requires are full
> run-time dependencies, meaning if a program uses libfoo which Requires
> libbar, the program will also want/have to use libbar's interface; OTOH
> Requires.private are "link-time" dependencies, i.e. libfoo dynamically
> links to libbar, so libbar needs to exist on the system at run-time, but
> a program using libfoo needn't use libbar's interface.

My reading of pkg-config(1) is that Requires.private is taken into
account only for ‘pkg-config foo --static --cflags/--libs’:

   Requires.private:
          A list of packages required by this package. The difference
          from Requires is that the packages listed under
          Requires.private are not taken into account when a flag list
          is computed for dynamically linked executable (i.e., when
          --static was not specified).

This is analogous to Libs.private in that regard.

In practice, we usually only care about shared libraries, thus...

> This would mean that Requires should be propagated inputs, and
> Requires.private only normal inputs;

... is mostly correct.  “Mostly,” because it might be that, unless
--static is passed, things in Requires.private don’t even need to be
present.

Do you have an example of a package that uses Requires.private?

> However, pkg-config isn't aware of compile-time/run-time dependency
> differences; it's considered an error if a Requires.private of libfoo
> isn't found,

Really, even without --static?

> because as far as pkg-config is concerned, it means libfoo is
> dysfunctional.  So we *do* need to propagate Requires.private, for the
> sake of pkg-config.  (The problem mainly manifests in the form of
> ./configure scripts claiming libfoo isn't found when it's only libbar
> that's missing, because in that case pkg-config returns an error to
> the ./configure script when inquired about libfoo.)

Do you have an example of that?

> P.S.: I'll see if I can write a tool that compares the union of the
> Requires[.private] fields of all .pc files in a package to the package's
> propagated inputs, so we can detect mismatches automatically.

Would be neat!

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]