Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

[Simon McVittie]

On Wed, 04 Apr 2018 at 10:41:01 +0300, Adrian Bunk wrote:
> On Wed, Apr 04, 2018 at 09:10:31AM +0200, Axel Beckert wrote:
> >...
> > ~ → ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
> >         libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x76e3f000)
> >         libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x76df7000)
> >         libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x76de4000)
> >         libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x76d0d000)
> >...
> 
> This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/ 
> that shouldn't be there, and this takes precedence over the more recent
> one from the Debian package that gets installed to /usr/lib.

My thoughts exactly. What's that doing there? I would have expected that
removing the old libglib2.0-0 package would delete that.

Please try:

ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*
ls -il /usr/lib/arm-linux-gnueabihf/libglib-2.0.so*

Since you were seeing these symbol lookup errors while packages are
being configured, I wonder whether we're seeing something like this:

* new libglib2.0-0 is unpacked
  - /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0 has been created
    (it is hard-linked to
    /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-new or something)
  - /lib/arm-linux-gnueabihf/libglib-2.0.so.0 has not yet been deleted
    (it is hard-linked to
    /lib/arm-linux-gnueabihf/libglib-2.0.so.0.dpkg-old or something)
* assorted other packages are unpacked
* assorted other packages are configured
  - in your situation, we fail here and never get further
* new libglib2.0-0 is configured
  - /lib/arm-linux-gnueabihf/libglib-2.0.so.0 should be deleted here

If that guess is correct, then we're going to have difficulty whenever we
migrate a library from a higher-precedence directory (/lib/MULTIARCH) to
a lower-precedence directory (/usr/lib/MULTIARCH), and we'd have the same
issue moving a non-multiarch library from /lib to /usr/lib. The multiarch
directories (from ld.so.conf.d) are higher-precedence than the non-multiarch
directories (hard-coded), so we only coincidentally avoided this for the
migration from non-multiarch to multiarch.

GLib maintainers following testing/unstable wouldn't have seen this
failure mode, because we would be very likely to be upgrading from a
version that is recent enough that it already has all the same symbols as
the one in /lib; but it would be a problem for stretch -> buster upgrades.

    smcv