Re: Build problem with binutils 2.3.2 / gcc 8.3.1: "DSO missing from command line"

[Knut Petersen]

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