[Top][All Lists]

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

bug#32995: Executing pre-compiled binaries

From: Ricardo Wurmus
Subject: bug#32995: Executing pre-compiled binaries
Date: Tue, 09 Oct 2018 15:02:43 +0200
User-agent: mu4e 1.0; emacs 26.1

Hi Brett,

> Brett Gilio writes:
>> Hi all, I am having an issue with trying to execute literally any
>> pre-compiled binary files. One example is Telegram. Here is what is
>> happening.
>> address@hidden ~$ cd Downloads/tsetup.1.4.0/Telegram/
>> address@hidden ~/Downloads/tsetup.1.4.0/Telegram$ ls
>> Telegram  Updater
>> address@hidden ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram bash:
>> ./Telegram:
>> No such file or directory
>> address@hidden ~/Downloads/tsetup.1.4.0/Telegram$
>> Any ideas?
> Also, in the strings evaluation of the binary I am getting
> /lib64/ld-linux-x86-64.so.2

This is the dynamic linker/loader.  It is provided by the GNU C library.
The best approach is to avoid this problem and build the programme from

Any other approach is really just a hack.  Possible hacks are:

1. symlink the dynamic linker/loader from glibc to the expected

2. use “patchelf” to replace the reference to the linker on an FHS
system with a reference to the linker from our glibc.

This would only be the first step.  Binaries built and linked elsewhere
are probably also going to have problems finding libraries.  Here you
would have to mess with LD_LIBRARY_PATH to satisfy these requirements.
I suggest not going down this road and packaging the software instead.

Since we don’t support the execution of pre-built binaries on Guix I’m
closing the bug report, but I hope my comments have been helpful in your


reply via email to

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