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.
