Bug#896019: libglib2.0-0: undefined symbol g_date_copy breaking many programs

Simon McVittie smcv at debian.org
Sun Dec 30 20:30:18 GMT 2018


On Mon, 03 Dec 2018 at 19:57:39 -0800, Xilin Sun wrote:
> my /lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.1
> my /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 was a symlink to
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5800.1

I wondered whether it was significant that GLib 2.48.0 was in
jessie-backports, but your obsolete shared library looks like it came
from 2.48.1, so it's probably coincidence.

Please send the output of these to the bug address (some of them will
give error messages, that's fine; please send those too):

ls -il /lib/x86_64-linux-gnu/libglib-2.0.so.*
ls -il /lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/libglib-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/libgobject-2.0.so.*
ls -il /usr/lib/x86_64-linux-gnu/libglib-2.0.so.*
ls -il /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /usr/lib/x86_64-linux-gnu/libglib-2.0.so.*
dpkg-query -S /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.*
dpkg-query -S /lib/x86_64-linux-gnu/*.so.* > /dev/null
dpkg-query -S /usr/lib/x86_64-linux-gnu/*.so.* > /dev/null

Also please look in /var/log/apt for the upgrade history of your
libglib2.0-0 package (as far back as you can), tell us what the sequence
of versions was, and check whether the upgrade transactions involving
libglib2.0-0 logged any warnings or unusual messages in term.log.

What is the history of this machine? What version of Debian did you
originally install, and when did you switch the apt sources to take
packages from sid? (For instance the answer might be "installed wheezy,
upgraded to jessie, switched from jessie to sid in late 2016".)

> Now that GLib puts these files under /usr/lib/x86_64-linux-gnu/, my
> /lib/x86_64-linux-gnu/libglib-2.0.so.* files from an old version of
> glib should certainly have been deleted during the installation of the
> new version, but somehow this didn't happen.

I'm surprised that dpkg can get into a situation where that can happen.

> I suppose one way to reproduce this bug is to install the system with
> libglib2.0–0 around version 2.48 and then do an upgrade to the latest
> version.

I tried installing GLib 2.42 from jessie (as seen in the original
bug report) and upgrading that, but my test VM doesn't have this bug
afterwards.

If it was that easy to reproduce, all Debian users with GLib installed
(including its maintainers) would have experienced this bug at the time
of the transition from GLib in /lib to GLib in /usr/lib, so there must
be some other factor involved. It's also noticeable that the stale GLib
versions are relatively old - probably not the most recently-installed.

On Mon, 03 Dec 2018 at 20:10:02 -0800, Xilin Sun wrote:
> By comparing the file lists of package libglib2.0-0 in stretch and
> sid, I think the old copy of libglib in /lib/x86_64-linux was
> introduced by the package itself, not 3rd party installers.

The file lists don't really prove anything either way: all we know is
that something installed an older copy of GLib to the same path that
an old Debian package would have used. Do you use any third-party apt
sources, or do you have any third-party software installed that runs as
root?

Thanks,
    smcv



More information about the pkg-gnome-maintainers mailing list