Executing pre-compiled binaries

  • Done
  • quality assurance status badge
Details
2 participants
  • Brett Gilio
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Brett Gilio
Severity
normal

Debbugs page

Brett Gilio wrote 6 years ago
(address . bug-guix@gnu.org)
87r2gz68by.fsf@posteo.net
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.

brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
Telegram Updater
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram
bash: ./Telegram: No such file or directory
brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$

Any ideas?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/| https://emacs.org
Brett Gilio wrote 6 years ago
(name . Brett Gilio)(address . brettg@posteo.net)(address . 32995@debbugs.gnu.org)
87pnwj67th.fsf@posteo.net
Brett Gilio writes:

Toggle quote (16 lines)
> 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.
>
> brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
> Telegram Updater
> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram
> bash: ./Telegram:
> No such file or directory
> brettg@oryxpro ~/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
Ricardo Wurmus wrote 6 years ago
(name . Brett Gilio)(address . brettg@posteo.net)(address . 32995-done@debbugs.gnu.org)
874ldvqnm4.fsf@elephly.net
Hi Brett,

Toggle quote (19 lines)
> 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.
>>
>> brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
>> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
>> Telegram Updater
>> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram bash:
>> ./Telegram:
>> No such file or directory
>> brettg@oryxpro ~/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
source.

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

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

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
case.

--
Ricardo
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 32995@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 32995
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help