[Top][All Lists]

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

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

From: Knut Petersen
Subject: Re: Build problem with binutils 2.3.2 / gcc 8.3.1: "DSO missing from command line"
Date: Mon, 3 Jun 2019 10:14:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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/, lily/, lily/, lily/, lily/, lily/, 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 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 <> 
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.


reply via email to

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