GNU bug report logs - #32995
Executing pre-compiled binaries

Previous Next

Package: guix;

Reported by: Brett Gilio <brettg <at> posteo.net>

Date: Tue, 9 Oct 2018 04:42:01 UTC

Severity: normal

Done: Ricardo Wurmus <rekado <at> elephly.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32995 in the body.
You can then email your comments to 32995 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#32995; Package guix. (Tue, 09 Oct 2018 04:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brett Gilio <brettg <at> posteo.net>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 09 Oct 2018 04:42:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Brett Gilio <brettg <at> posteo.net>
To: bug-guix <at> gnu.org  
Subject: Executing pre-compiled binaries
Date: Mon, 08 Oct 2018 23:40:49 -0500
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 <at> oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
Telegram  Updater
brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram 
bash: ./Telegram: No such file or directory
brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$

Any ideas?


-- 
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org




Information forwarded to bug-guix <at> gnu.org:
bug#32995; Package guix. (Tue, 09 Oct 2018 04:53:02 GMT) Full text and rfc822 format available.

Message #8 received at 32995 <at> debbugs.gnu.org (full text, mbox):

From: Brett Gilio <brettg <at> posteo.net>
To: Brett Gilio <brettg <at> posteo.net>
Cc: 32995 <at> debbugs.gnu.org
Subject: Re: bug#32995: Executing pre-compiled binaries
Date: Mon, 08 Oct 2018 23:51:54 -0500
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 <at> oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
> brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
> Telegram  Updater
> brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram 
> bash: ./Telegram:
> No such file or directory
> brettg <at> 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





Reply sent to Ricardo Wurmus <rekado <at> elephly.net>:
You have taken responsibility. (Tue, 09 Oct 2018 14:49:02 GMT) Full text and rfc822 format available.

Notification sent to Brett Gilio <brettg <at> posteo.net>:
bug acknowledged by developer. (Tue, 09 Oct 2018 14:49:02 GMT) Full text and rfc822 format available.

Message #13 received at 32995-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Brett Gilio <brettg <at> posteo.net>
Cc: 32995-done <at> debbugs.gnu.org
Subject: Re: bug#32995: Executing pre-compiled binaries
Date: Tue, 09 Oct 2018 15:02:43 +0200
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.
>>
>> brettg <at> oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/
>> brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls
>> Telegram  Updater
>> brettg <at> oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram bash:
>> ./Telegram:
>> No such file or directory
>> brettg <at> 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





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 07 Nov 2018 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 226 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.