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