Hi Werner!
I always thought that `pkg-config' resolves dependencies recursively.
Even with your `pangoft2.pc' file it should check the dependencies in
`pango.fc', right? And there I see
Requires: glib-2.0 gobject-2.0
Tumbleweed also moved those dependencies to 'Require.private' ;-)
But I guess this looks different for you, too.
Maybe a packaging error of pango?
It seems we have to add a test for pango to circumvent the problem...
We do use glib-2.0 and gobject-2.0 symbols directly (at least in lily/all-font-metrics.cc, lily/general-scheme.cc, lily/pano-font.cc, lily/pango-select.cc, lily/pango-select-scheme.cc, lily/pdf-scheme.cc), but we do not explicitly test for and link against the glib-2.0 and gobject-2.0 shared
libraries. That works as long as the pango.pc and/or pangoft2.pc includes those libs after "Requires".
According to https://people.freedesktop.org/~dbn/pkg-config-guide.html the
openSuSE Tumbleweed pangoft2.pc is correct:
The most important pkg-config metadata fields are Requires,
Requires.private, Cflags, Libs and Libs.private. They will define the metadata
used by external projects to compile and link with the library.
Requires and Requires.private define other modules needed by the library. It
is usually preferred to use the private variant of Requires to avoid exposing
unnecessary libraries to the program that is linking with your library. If the
program will not be using the symbols of the required library,
it should not be linking directly to that library. See the discussion of
overlinking <https://wiki.openmandriva.org/en/Overlinking_issues_in_packaging>
for a more thorough explanation.
Since pkg-config always exposes the link flags of the Requires libraries,
these modules will become direct dependencies of the program. On the other
hand, libraries from Requires.private will only be included when static
linking. For this reason, it is usually only appropriate to add modules
from the same package in Requires.
The Libs field contains the link flags necessary to use that library. In
addition, Libs and Libs.private contain link flags for other libraries not
supported by pkg-config. Similar to the Requires field, it is preferred to add
link flags for external libraries to the Libs.private field so
programs do not acquire an additional direct dependency.
Finally, the Cflags contains the compiler flags for using the library.
Unlike the Libs field, there is not a private variant of Cflags. This is
because the data types and macro definitions are needed regardless of the
linking scenario.
I think it is clear that we really need to test for and link against the
glib-2.0 and gobject-2.0 libraries.
Knut
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
