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,

Michael Biebl wrote:
> >> As soon as you clean up the stray
> >> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
> >> problem should go away?
> > 
> > No, because there's also a symlink to it which (according to the
> > timestamp) seem to have been created by maintainer scripts of this
> > package:
> > 
> > 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
> > 
> > Not sure how I should clean up that one. Can I safely delete it, too?
> 
> Running ldconfig should take care of removing the stray symlink.
> It was ldconfig which created the symlink, afaik.

Worked, thanks! (Both, emacs and gio-querymodules, work again.)

Feel free to close the bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , 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

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

[Michael Biebl]

Am 04.04.2018 um 21:27 schrieb Axel Beckert:

>> As soon as you clean up the stray
>> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
>> problem should go away?
> 
> No, because there's also a symlink to it which (according to the
> timestamp) seem to have been created by maintainer scripts of this
> package:
> 
> 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
> 
> Not sure how I should clean up that one. Can I safely delete it, too?

Running ldconfig should take care of removing the stray symlink.
It was ldconfig which created the symlink, afaik.






signature.asc
Description: OpenPGP digital signature

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 Michael,

Michael Biebl wrote:
> Do you have an idea, where this file might have come from?

On a first thought: No. The package is no package I installed on
purpose, it came in by dependencies and I surely didn't fiddle around
with its configuration (if it has one).

On a second thought: I know that in the very beginning of that system
(i.e. during 2015) I had issues with the SD card the system runs off
and I at least replaced the SD card once, maybe twice. IIRC the
original SD card went readonly and I dd'ed its contents onto a new one
and ran fsck (offline). While that in theory could cause stray files,
IMHO especially dpkg is rather good in keeping things consistent.

So I slightly doubt that this is the cause for this issue. On the
other hand, it seems the best explanation currently available.

> So it looks like a local misconfiguration which went unnoticed so far as
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.5* took precedence over
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

I have no idea what kind of "configuration" could be involved here.

> I guess there is nothing really the libglib2.0-0 package can do about
> this. Do you agree?

If I'm the only one who happens to have this issue, I'm fine with
closing this as unreproducible.

> As soon as you clean up the stray
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
> problem should go away?

No, because there's also a symlink to it which (according to the
timestamp) seem to have been created by maintainer scripts of this
package:

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

Not sure how I should clean up that one. Can I safely delete it, too?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , 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

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

[Michael Biebl]

Am 04.04.2018 um 21:06 schrieb Michael Biebl:
> Am 04.04.2018 um 20:20 schrieb 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
> 
> Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> coming from?
> Does dpkg list it as owned by any package?

Sorry, somehow completely missed the following paragraph where you
answered that already.

Do you have an idea, where this file might have come from?

So it looks like a local misconfiguration which went unnoticed so far as
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.5* took precedence over
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

I guess there is nothing really the libglib2.0-0 package can do about
this. Do you agree?
As soon as you clean up the stray
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
problem should go away?



signature.asc
Description: OpenPGP digital signature

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,

Michael Biebl wrote:
> >> 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
> 
> Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> coming from?

I don't know.

> Does dpkg list it as owned by any package?

Please read my previous mail a few lines further than you cited it.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , 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

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

[Michael Biebl]

Am 04.04.2018 um 20:20 schrieb 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

Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
coming from?
Does dpkg list it as owned by any package?



signature.asc
Description: OpenPGP digital signature

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

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

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

[Adrian Bunk]

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.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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,

Simon McVittie wrote:
> > emacs25: symbol lookup error: 
> > /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: 
> > g_date_copy
[fast forward → TL;DR]

> In fact, running
> 
> LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
> 
> and seeing whether it fails might also give interesting information.

It fails in the same way as emacs fails:

~ → 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

Downgrading helps also here:

~ → LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
Usage: gio-querymodules  [ ...]
Will update giomodule.cache in the listed directories

For completeness, following is the remainder of the questions with the
long answers. ;-)

> I would normally ask: if you run `ldd emacs25`, what does it say?

Ah, right. Should have done that in the initial mail:

~ → emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
~ → ldd =emacs25
libtiff.so.5 => /usr/lib/arm-linux-gnueabihf/libtiff.so.5 (0x76ec3000)
libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x76e8a000)
libpng16.so.16 => /usr/lib/arm-linux-gnueabihf/libpng16.so.16 
(0x76e59000)
libgif.so.7 => /usr/lib/arm-linux-gnueabihf/libgif.so.7 (0x76e43000)
libXpm.so.4 => /usr/lib/arm-linux-gnueabihf/libXpm.so.4 (0x76e27000)
libXaw3d.so.6 => /usr/lib/arm-linux-gnueabihf/libXaw3d.so.6 (0x76dd3000)
libXmu.so.6 => /usr/lib/arm-linux-gnueabihf/libXmu.so.6 (0x76db3000)
libXt.so.6 => /usr/lib/arm-linux-gnueabihf/libXt.so.6 (0x76d68000)
libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x76d52000)
libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x76d31000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x76d16000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c21000)
libX11-xcb.so.1 => /usr/lib/arm-linux-gnueabihf/libX11-xcb.so.1 
(0x76c0f000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76be7000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 
(0x76bd)
libXft.so.2 => /usr/lib/arm-linux-gnueabihf/libXft.so.2 (0x76bb2000)
libasound.so.2 => /usr/lib/arm-linux-gnueabihf/libasound.so.2 
(0x76afd000)
librsvg-2.so.2 => /usr/lib/arm-linux-gnueabihf/librsvg-2.so.2 
(0x76ac9000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76a48000)
libgio-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0 
(0x7693a000)
libgdk_pixbuf-2.0.so.0 => 
/usr/lib/arm-linux-gnueabihf/libgdk_pixbuf-2.0.so.0 (0x7691)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 
(0x768c8000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 
(0x767ef000)
libcairo.so.2 => /usr/lib/arm-linux-gnueabihf/libcairo.so.2 (0x76731000)
libMagickWand-6.Q16.so.5 => 
/usr/lib/arm-linux-gnueabihf/libMagickWand-6.Q16.so.5 (0x7664b000)
libMagickCore-6.Q16.so.5 => 
/usr/lib/arm-linux-gnueabihf/libMagickCore-6.Q16.so.5 (0x7643b000)
libacl.so.1 => /lib/arm-linux-gnueabihf/libacl.so.1 (0x76425000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x7640f000)
libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0x763ce000)
libXrandr.so.2 => /usr/lib/arm-linux-gnueabihf/libXrandr.so.2 
(0x763b7000)
libXinerama.so.1 => /usr/lib/arm-linux-gnueabihf/libXinerama.so.1 
(0x763a4000)
libXfixes.so.3 => /usr/lib/arm-linux-gnueabihf/libXfixes.so.3 
(0x7639)
libxml2.so.2 => /usr/lib/arm-linux-gnueabihf/libxml2.so.2 (0x7626d000)
libgpm.so.2 => /usr/lib/arm-linux-gnueabihf/libgpm.so.2 (0x76256000)
libtinfo.so.5 => /lib/arm-linux-gnueabihf/libtinfo.so.5 (0x7622b000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x76201000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 
(0x76185000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 
(0x76146000)
libotf.so.0 => /usr/lib/arm-linux-gnueabihf/libotf.so.0 (0x76127000)
libm17n-core.so.0 => /usr/lib/arm-linux-gnueabihf/libm17n-core.so.0 
(0x760fa000)
libm17n-flt.so.0 => /usr/lib/arm-linux-gnueabihf/libm17n-flt.so.0 
(0x760e2000)
libgnutls.so.30 => /usr/lib/arm-linux-gnueabihf/libgnutls.so.30 
(0x75fdf000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x75fba000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x75f98000)
libgomp.so.1 => /usr/lib/arm-linux-gnueabihf/libgomp.so.1 (0x75f68000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x75e7)
/lib/ld-linux-armhf.so.3 (0x76f3d000)

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 00:51:04 +0200, Axel Beckert wrote:
> since very recently, emacs25 on armhf (but not on amd64) crashes for
> me as follows:
> 
> emacs25: symbol lookup error: 
> /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: 
> g_date_copy

I would normally ask: if you run `ldd emacs25`, what does it
say? But this is emacs, so the answer is quite possibly "too much".
`ldd /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules` might give
a more concise answer that still contains the information I'm looking for.

In fact, running

LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules

and seeing whether it fails might also give interesting information.
(If successful, it should just print a usage message saying it requires
at least one  parameter.)

> Since emacs25 itself was last uploaded in 2017, i.e. over three months
> ago, I assumed the culprit is hidden in the very recently updated
> libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
> causes the issue to vanish.

There were no source code changes in upgrading libglib2.0-0 from 2.56.0-4
to 2.56.0-5, so it really shouldn't have lost any symbols; and if it did,
that should have caused FTBFS when it didn't match its .symbols file.

One major change in 2.56.0-5 is that libglib2.0.so.0 moved from
/lib/MULTIARCH to /usr/lib/MULTIARCH, which makes me wonder whether you
have an outdated version of GLib elsewhere in your library search path
or elsewhere in emacs25's RPATH or RUNPATH, such that the outdated version
was found after /lib/MULTIARCH but before /usr/lib/MULTIARCH?

Another possibility is that emacs25 might do something horrible during
its startup that makes it rely on absolute paths to libraries (I don't
use emacs myself, but I dimly remember rumours of it using a core dump
to optimize its own startup). But if it does that, then I would have
expected it to break equally badly whenever a library moves to the
multiarch directory?

smcv

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]

Package: libglib2.0-0
Version: 2.56.0-5
Severity: grave
Control: affects -1 + emacs25

Dear Maintainers,

since very recently, emacs25 on armhf (but not on amd64) crashes for
me as follows:

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

Since emacs25 itself was last uploaded in 2017, i.e. over three months
ago, I assumed the culprit is hidden in the very recently updated
libglib2.0-0 package. And indeed, downgrading libglib2.0-0 to 2.56.0-4
causes the issue to vanish.

Due to emacs crashing, this issue also causes the postinst of every
elpa-* package and probably also every *-mode package to fail.

Actually this is where I noticed the issue first:

Setting up mmm-mode (0.5.5-2) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package mmm-mode (--configure):
 installed mmm-mode package post-installation script subprocess returned error 
exit status 1
Setting up elpa-gitattributes-mode (1.2.7-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-gitattributes-mode (--configure):
 installed elpa-gitattributes-mode package post-installation script subprocess 
returned error exit status 1
Setting up elpa-no-littering (0.5.13-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-no-littering (--configure):
 installed elpa-no-littering package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of elpa-git-modes:
 elpa-git-modes depends on elpa-gitattributes-mode (= 1.2.7-1); however:
  Package elpa-gitattributes-mode is not configured yet.

dpkg: error processing package elpa-git-modes (--configure):
 dependency problems - leaving unconfigured
Setting up elpa-ps-ccrypt (1.10-6) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-ps-ccrypt (--configure):
 installed elpa-ps-ccrypt package post-installation script subprocess returned 
error exit status 1
Setting up elpa-hl-todo (1.8.1-1) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
emacs25: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy
ERROR: install script from emacsen-common package failed
dpkg: error processing package elpa-hl-todo (--configure):
 installed elpa-hl-todo package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 mmm-mode
 elpa-gitattributes-mode
 elpa-no-littering
 elpa-git-modes
 elpa-ps-ccrypt
 elpa-hl-todo

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libglib2.0-0 depends on:
ii  libc62.27-3
ii  libffi6  3.2.1-8
ii  libmount12.31.1-0.5
ii  libpcre3 2:8.39-9
ii  libselinux1  2.7-2+b2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.56.0-5
ii  shared-mime-info  1.9-2
pn  xdg-user-dirs 

libglib2.0-0 suggests no packages.

-- no debconf information