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 Bugfirstname.lastname@example.org https://lists.gnu.org/mailman/listinfo/bug-make