Bugzilla Bug 92626

After emerging pkgconfig-0.17.2, pkg-config --libs does not return flags for
dependencies. This breaks for example the emerge of openoffice-ximian-1.3.11
After going back to pkgconfig-0.15.0, pkg-config --libs returns the expected
result. 
(I will be able to tell tomorrow if the emerge of openoffice-ximian-1.3.11 now
succeeds)


Reproducible: Always
Steps to Reproduce:
1. pkg-config --libs gtk+-2.0 gdk-pixbuf-xlib-2.0

Actual Results:  
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk_pixbuf_xlib-2.0

Expected Results:  
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoxft-1.0
-lpangox-1.0 -lpango-1.0 -lgdk_pixbuf_xlib-2.0 -lgdk_pixbuf-2.0 -lm
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

From pkgconfig configure.in:

#
# Code taken from gtk+-2.0's configure.in.
#
# This causes pkg-config to only list direct dependencies on platforms
# which support inter-library dependencies.
#

AC_ARG_ENABLE(indirect-deps,
        [AC_HELP_STRING([--enable-indirect-deps],
                              [list both direct and indirect dependencies.])
AC_HELP_STRING([--disable-indirect-deps],
                              [only list direct dependencies.])
    [default=auto]],use_indirect_deps=$enableval,
    [use_indirect_deps=auto])
echo use_indirect_deps=$use_indirect_deps >&AS_MESSAGE_LOG_FD
AC_MSG_CHECKING([whether to list both direct and indirect dependencies])
case $use_indirect_deps in
  auto)
    deplibs_check_method=`(./libtool --config; echo eval echo \$deplibs_check_method) | sh`
    if test "X$deplibs_check_method" = Xnone; then
    echo "foo: $deplibs_check_method" >&AS_MESSAGE_LOG_FD
      use_indirect_deps=yes
    else
      use_indirect_deps=no
    fi
  ;;
  yes|no)
  ;;
  *) AC_MSG_ERROR([Value given to --enable-indirect-deps must be one of yes, no
or auto])
  ;;
esac
AC_MSG_RESULT($use_indirect_deps)

Indeed, adding --enable-indirect-deps=yes to EXTRA_ECONF gives the expected behaviour.

Perhaps this means that this is a bug in libtool?

This should be fixed in pkgconfig-0.17.2-r1. Apparently, the pkgconfig
maintainers wanted to implement something similar to the suggestion in
http://bugs.gnome.org/show_bug.cgi?id=145494, but did it as a compile-time
option instead of a run-time flag, causing breakage in a good number of regular
situations.

Thanks for the notice.

Well actually i support the attempt to remove unneeded libs from the linker
output, this is afaik what causes the problems that force ppl to do major
(revdep) rebuilds when binary versioning of a lowlevel dep changes.

Although I'm not completely sure that pkgconfig 0.17 plain atm is doing the
right thing, we shouldn't be discarding it. Some packages that use pkgconfig for
linking may need fixing if they were based on wrong assumptions.

Not sure that it's the packages themselves that are broken; it seems that
simply
trying to link against a C++ library with dependencies fails when dependency
flags are omitted:

$ echo "int main (int argc, char **argv) { return 0; }" > foo.cpp
$ g++ foo.cpp $(sed 's/^Libs:/echo/;t;/^\w\+: /d'
/usr/lib/pkgconfig/gtkmm-2.4.pc | sh)
/usr/lib/libgtkmm-2.4.so: undefined reference to `Gdk::Color::~Color()'
/usr/lib/libgtkmm-2.4.so: undefined reference to
`Atk::Implementor::ref_accessibile_vfunc()'
/usr/lib/libgtkmm-2.4.so: undefined reference to
`Glib::wrap(_GdkPixbufAnimation*, bool)'
/usr/lib/libgtkmm-2.4.so: undefined reference to `Glib::wrap(_GdkWindowObject*,
bool)'
/usr/lib/libgtkmm-2.4.so: undefined reference to
`Gdk::AtomStringTraits::to_cpp_type(_GdkAtom*)'
/usr/lib/libgtkmm-2.4.so: undefined reference to `Gdk::Pixbuf::get_base_type()'
/usr/lib/libgtkmm-2.4.so: undefined reference to `Glib::wrap(_GdkVisual*,
bool)'
...

In which case, could this be a bug in binutils?

I didn't run up against the evolution error before installing the new
pkgconfig,
but perhaps that has a similar cause?

Or... that's what's meant to happen, and everyone should be using libtool, as
that correctly calculates the dependencies to pass to ld?

so how does this problem work out with pkgconfig-0.18.1 altered to disable
indirect deps ? Why did you default to the old behaviour anyway leonardo, ~arch
is to test these things.

Disabling indirect deps might break compilation in packages that rely in the
old
behaviour and don't set the correct public and private dependencies in the .pc
file. In case someone is interested, a summary of the situation is described in
https://bugs.freedesktop.org/show_bug.cgi?id=3060

Since version 0.18 pkgconfig provides the directive 'Libs.private' so packages
relying on the old behaviour can be fixed if necessary. Enabling indirect deps
by default really is a work-around to temporally avoid those problems. 

So basically restoring the default behaviour (disabling indirect deps) may
start
unveiling easy bugs that could be fixed and reported upstream, it's just a
matter of when do we want to do that :). I'm currently working on stabilizing
gnome-2.10.1 and preparing gnome-2.10.2.

I know about the issues involved, thats why I questioned the enabling. To
return
to my earlier comment : ~arch is to test these things.

since pkgconfig needed a bump anyway (#100012), I added -r1 with indirect deps
disabled.

Since we are going with the default option now (disabling indirect deps), I'm
resolving this as WONTFIX.

Any problems caused by this should be reported in new bugs so the relevant
packages can be fixed. Thanks.