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

[Axel Beckert]

Hi,

Simon McVittie wrote:
> > 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*

6080 lrwxrwxrwx 1 root root     23 Apr  4 09:03 /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
1563 -rw-r--r-- 1 root root 814280 Nov 13  2014 /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

So while the symlink is rather new (corresponds to the time when I
upgraded the package again to answer your questions, i.e. it seems the
package upgrade time), the libglib-2.0.so.0.4200.1 is rather old on
the other hand. And dpkg doesn't seem to know that file:

$ dpkg -S /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
dpkg-query: no path found matching pattern /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

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

16493 lrwxrwxrwx 1 root root     23 Apr  1 17:59 /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.0
 6859 -rw-r--r-- 1 root root 837824 Apr  1 17:59 /usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0.5600.0

> Since you were seeing these symbol lookup errors while packages are
> being configured,

JFTR: Not only then, also after the apt or aptitude run is finished,
i.e. I still see this:

$ emacs
emacs: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

> * assorted other packages are configured
>   - in your situation, we fail here and never get further

No. libglib2.0-0 never failed to upgrade or downgrade (in the past few
days). Just some elpa-* packages and it weren't enough to abort the
whole run.

Additionally, I was able to upgrade them successfully after
downgrading libglib2.0-0. Now they are upgraded and I've upgraded
libglib2.0-0 again (without any issues _during_ the upgrade as no
other affected packages were upgraded in the same run) and now Emacs
crashes again as before:

$ emacs
emacs: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

As does gio-querymodules:

$ LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

> 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.

JFTR: This is a Debian Sid installation which is usually dist-upgraded
at least every few days since early 2015 or so, i.e. not recently
upgraded from Stretch. There was "stretch" instead of "testing" in the
sources.list until recently, though. Noticed it when I wanted to
downgrade libglib2.0-0 to the version from testing. But fixing this
didn't make any difference as it didn't cause any previously
impossible upgrades or so to show up. And sid was always present in
the sources.list.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE