On Thu, Feb 22, 2018 at 08:51:09AM -0500, Paul Smith wrote:
> On Thu, 2018-02-22 at 10:53 +0000, dimp...@cs.ox.ac.uk wrote:
> > While building a project (https://github.com/sagemath/sage)
> > on Arch Linux (which provides Guile-enabled GNU make)
> > we have encountered make crashes which look as follows
> >
> > make: symbol lookup error: /usr/lib/libguile-2.2.so.1: undefined symbol:
> > GC_move_disappearing_link
>
> That message is not generated by make, and make does not use the symbol
> GC_move_disappearing_link.
this symbol is used by Guile, and make is build (in this case) with
Guile support. Thus I don't understand what you mean by "make is not
using the symbol". Its extension does use it.
>
> This error is generated by your runtime linker (ld.so), which is trying
> to load all the shared libraries linked into your application (in this
> case GNU make) before any of the application code is even started. GNU
> make can't "shield" itself from this problem: it's not even running
> yet.
yes, it can - e.g. by statically linking libguile and its dependencies,
or using a less standard way of dynamic linking which is immune to
changes in the envirnoment.
Otherwise using GNU make with Guile extenion gets difficult (if not
impossible) for doing work involving changes to any of Guile dependencies,
and there are plenty:
$ ldd `which make` # with Guile
linux-vdso.so.1 (0x00007fff3ccf6000)
libguile-2.2.so.1 => /usr/lib/libguile-2.2.so.1 (0x00007f88df74d000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f88df549000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f88df32b000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f88def74000)
libgc.so.1 => /usr/lib/libgc.so.1 (0x00007f88ded0a000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f88deb01000)
libunistring.so.2 => /usr/lib/libunistring.so.2 (0x00007f88de77f000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f88de4ec000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f88de2e2000)
libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f88de0aa000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f88ddd5e000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
(0x00007f88dfa7a000)
libatomic_ops.so.1 => /usr/lib/libatomic_ops.so.1 (0x00007f88ddb5c000).
vs
$ ldd `which make` # without Guile
linux-vdso.so.1 (0x00007ffe861ce000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0e5b6d3000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0e5b30f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0e5b8d7000)
Thanks for looking into this,
Dmitrii
PS. here are more details - I should have included this link in the
original message:
https://trac.sagemath.org/ticket/24575
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
