[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LIBRARY_PATH and foreign binaries: error while loading shared librar

From: Ricardo Wurmus
Subject: Re: LIBRARY_PATH and foreign binaries: error while loading shared libraries
Date: Wed, 18 Apr 2018 22:39:04 +0200
User-agent: mu4e 1.0; emacs 25.3.1

Hi Pierre,

>> /path/to/foreign/binary
> /path/to/foreign/binary: No such file or directory
> This is because the path to the linker is wrong:
>> file /path/to/foreign/binary
> /path/to/foreign/binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
> dynamically linked, interpreter /lib64/, for GNU/Linux 
> 2.6.24, BuildID[sha1]=edf4cff78e6710ff4f7ac14cb99b38aefed2659e, stripped
> I can fix it with
>> patchelf --set-interpreter "$(realpath "$(which sh)")" 
>> /path/to/foreign/binary
> (Is this the commended way?)

It is one way that ensures that the correct linker is used.  Another way
is to install the glibc’s dynamic linker in the expected location at

> The "missing" libraries are indeed in my ~/.guix-profile/lib.  This
> folder is properly referenced in the environment:
>> env | grep LIBRARY_PATH
> LIBRARY_PATH=/home/ambrevar/.guix-profile/lib

> My understanding is that the LIBRARY_PATH is only used for compiling,

Correct.  It is respected by the linker.

> not at runtime.  But then how come some libraries are found and not
> others?

That’s probably because the libraries it found end up there because of
patching the interpreter.

> If I export LD_LIBRARY_PATH to the value of LIBRARY_PATH, then it works:
>> /path/to/foreign/binary
> Is there a better way?

The best way is to build the software from source.  Short of that you
can load individual libraries with LD_PRELOAD.  The most coarse-grain
solution is to use LD_LIBRARY_PATH.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]