André A. Gomes <andremegaf...@gmail.com> writes:
Pan Xie <xie...@skyguard.com.cn> writes:
scheme can't start up with LD_LIBRARY_PATH set:
$ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme
Segmentation fault (core dumped)
$ LD_LIBRARY_PATH='/usr/lib' scheme
Segmentation fault (core dumped)
The question by Pan has been answered but I have questions on
this topic:
What's the cause of this segmentation fault on Guix?
Is there a way to use chez scheme installed via Guix to see the
shared
library at /usr/lib (instead of installing the package that
provides it
it via Guix)?
Generally, this is not possible. It's not a problem that's
limited to Guix.
You cannot generally assume that libraries from different sources
are ABI compatible. Segfaults like this are often the result of
forcibly joining binaries with incompatible ABIs. The ABI is a
contract between different binaries that allows one binary to jump
straight into some offset of a library to execute instructions.
When that contract is broken or ignored (because the binaries
disagree on the offsets of the implementation of a named feature)
then an executable may jump into the void where it expected a
library to provide an implementation. This jump into the void is
punished by the kernel with termination of the executable.
LD_LIBRARY_PATH is a very blunt tool and it is meant for people
who know for a fact that the libraries contained in the given
directories implement a compatible ABI as the given executable.
On traditional systems with a single global store of compatible
libraries built with the same toolchain and linked with the same
set of "system" libraries throughout this assumption generally
holds. When more than one toolchain is used, however, all bets
are off.
--
Ricardo
