Appimage: cannot run binary file

Appimage: cannot run binary file

[Christophe Pisteur]

Hello,

I would like to use the development version of freecad (currently
freecad 0.19), but only stable freecad (freecad 0.18) is in the guix
package.

The alternative solution is to use the freecad Appimage (1) as explain
here (2) but it doesn't work on my guix system. 
Here are the error messages I get when I launch the freecad Appimage
from terminal:

$ . /home/christophe/Téléchargements/FreeCAD_0.19-23578-Linux-
Conda_glibc2.12-x86_64.AppImage
bash: .: /home/christophe/Téléchargements/FreeCAD_0.19-23578-Linux-
Conda_glibc2.12-x86_64.AppImage : ne peut exécuter le fichier binaire

(= cannot run binary file).

Any idea? 

Christophe 

(1) https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre
(2) https://wiki.freecadweb.org/AppImage

Re: Appimage: cannot run binary file

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

Bonjour Christophe!

Christophe Pisteur 写道：
> bash: .: 
> /home/christophe/Téléchargements/FreeCAD_0.19-23578-Linux-
> Conda_glibc2.12-x86_64.AppImage : ne peut exécuter le fichier 
> binaire

This unclear error message means that the dynamic linker/loader 
was not found.

It's an absolute file name, hard-coded in the executable.  In this 
case:

  λ file FreeCAD_0.19-23578-Linux-Conda_glibc2.12-x86_64.AppImage 
  ...ELF 64-bit LSB executable, x86-64, version 1 (SYSV)...
  ...dynamically linked, interpreter 
  /lib64/ld-linux-x86-64.so.2...
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Like Flatpaks (and all binaries, really), AppImages are 
distro-specific: they expect this file to exist at this exact 
location or they won't be able to start.  It won't run on my Guix 
System even though I have a compatibility symlink in /lib:

  (service special-files-service-type
           `(("/lib/ld-linux-x86-64.so.2"
              ,(file-append (canonical-package glibc)
                            "/lib/ld-linux-x86-64.so.2"))
             ...))

After adding one for /lib64 as well, this happens:

  λ ./FreeCAD_0.19-23578-Linux-Conda_glibc2.12-x86_64.AppImage 
  ...: error while loading shared libraries: libz.so.1: cannot 
  open
  shared object file: No such file or directory

Of course: there is no libz.so in /lib{,64} either!

Rather than add more compatibility links for every library and its 
sister, we create a Guix environment and hackily point our 
AppImage towards it:

  λ guix environment --ad-hoc zlib fuse -- bash -c \
    'LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib \
    ./FreeCAD_0.19-23578-Linux-Conda_glibc2.12-x86_64.AppImage'

  fusermount: mounting over filesystem type 0xca451a4e is 
  forbidden

  Cannot mount AppImage, please check your FUSE setup.
  You might still be able to extract the contents of this AppImage 
  if you run it with the --appimage-extract option. 
  See https://github.com/AppImage/AppImageKit/wiki/FUSE 
  for more information
  open dir error: No such file or directory

At this point I got a disgusting hunch:

  ~/linux λ grep -r 0xca451a4e *
  ... #define BCACHEFS_STATFS_MAGIC 0xca451a4e

A hard-coded file system whitelist[0]!  What could go wrong?

You'll probably get a different error on your system; it might 
even work.  You could try extracting it:

  /tmp/squashfs-root λ ./AppRun 
  bash: ./AppRun: /bin/bash: bad interpreter: No such file or 
  directory

  /tmp/squashfs-root λ bash ./AppRun 
  .../bin/freecad: error while loading shared libraries: 
  libGL.so.1:
  cannot open shared object file: No such file or directory

And so on until you have fun.  Much cross-distro; very universal. 
I tried adding mesa; didn't work.

Instead, I strongly recommend writing your own Guix package (using 
inherit) or looking for a less byzantine download format.

> (= cannot run binary file).

(Tip: you can submit ‘normalised’ bug reports by setting 
LC_ALL=C.)

Good luck,

T G-R

[0]: I don't know if it's in AppImage of FUSE, nor do I much care.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Appimage: cannot run binary file

[raingloom]

On Wed, 10 Feb 2021 19:59:17 +0100
Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> Instead, I strongly recommend writing your own Guix package (using 
> inherit) or looking for a less byzantine download format.

For a quick test, could try building it with one of the package
transformers:
https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html

Although copying the package definition into a Guile script, modifying
it, and loading it with --file or --expression is not that much harder
once you get the hang of it.

Re: Appimage: cannot run binary file

[Christophe Pisteur]

Bonjour Tobias!

Le mercredi 10 février 2021 à 19:59 +0100, Tobias Geerinckx-Rice a
écrit :
> Bonjour Christophe!
> 
> Instead, I strongly recommend writing your own Guix package (using 
> inherit) or looking for a less byzantine download format.

Thank you for these detailed explanations.

I see it's way beyond what I can do, but I get the point.

> 
> > (= cannot run binary file).
> 
> (Tip: you can submit ‘normalised’ bug reports by setting 
> LC_ALL=C.)

Thanks for the advice!
> 
> Good luck,

:-) 

> 
> T G-R
> 
> [0]: I don't know if it's in AppImage of FUSE, nor do I much care.

Christophe

Re: Appimage: cannot run binary file

[Christophe Pisteur]

Le jeudi 11 février 2021 à 05:25 +0100, raingloom a écrit :
> On Wed, 10 Feb 2021 19:59:17 +0100Tobias Geerinckx-Rice <me@tobias.gr
> > wrote:
> > Instead, I strongly recommend writing your own Guix package (using
> > inherit) or looking for a less byzantine download format.
> 
> For a quick test, could try building it with one of the
> packagetransformers:
> https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html
> 
> Although copying the package definition into a Guile script,
> modifyingit, and loading it with --file or --expression is not that
> much harderonce you get the hang of it.

I don't understand all the nuances of this discussion (I'm sorry), but
it seems to me that the problem is, in the case of the development
version of freecad, that the sources are not published regularly. The
sources were last published in 2019 (1), while freecad offers an
Appimage almost every week. So building something from the sources of
the development code doesn't add much value to the stable version. I
must certainly be missing something, so once again sorry.
Christophe
(1) https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre: " Note:
The development binaries are built regularly (You may need to expand
the assets tab) . The release date indicates the beginning of the dev
cycle. The commits indicates how many commits in the dev cycle. The
source archives (tar.gz and .zip) do not get updated, so they match the
commit of the tag (34a083b) and are therefore obsolete. You can get the
latest source here: 
https://github.com/FreeCAD/FreeCAD/archive/master.zip"

Re: Appimage: cannot run binary file

[Sergiu Ivanov]

Hi Christophe,

Thus quoth  Christophe Pisteur  on Thu Feb 11 2021 at 13:53 (+0100):
> Le jeudi 11 février 2021 à 05:25 +0100, raingloom a écrit :
>> On Wed, 10 Feb 2021 19:59:17 +0100Tobias Geerinckx-Rice <me@tobias.gr
>> > wrote:
>> > Instead, I strongly recommend writing your own Guix package (using
>> > inherit) or looking for a less byzantine download format.
>> 
>> For a quick test, could try building it with one of the
>> packagetransformers:
>> https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html
>> 
>> Although copying the package definition into a Guile script,
>> modifyingit, and loading it with --file or --expression is not that
>> much harderonce you get the hang of it.
>
> I don't understand all the nuances of this discussion (I'm sorry), but
> it seems to me that the problem is, in the case of the development
> version of freecad, that the sources are not published regularly. The
> sources were last published in 2019 (1), while freecad offers an
> Appimage almost every week. So building something from the sources of
> the development code doesn't add much value to the stable version. I
> must certainly be missing something, so once again sorry.
> Christophe
> (1) https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre: " Note:
> The development binaries are built regularly (You may need to expand
> the assets tab) . The release date indicates the beginning of the dev
> cycle. The commits indicates how many commits in the dev cycle. The
> source archives (tar.gz and .zip) do not get updated, so they match the
> commit of the tag (34a083b) and are therefore obsolete. You can get the
> latest source here: 
> https://github.com/FreeCAD/FreeCAD/archive/master.zip"

I don't know or use FreeCAD, but it looks like the source code is
updated quite regularly on their GitHub repository:

  https://github.com/FreeCAD/FreeCAD/

The latest changes seem to date back to several hours.

I'd say these are the sources from which the development binaries are
built (at least this is what is usually done).

My understanding of the sentence

> The source archives (tar.gz and .zip) do not get updated, so they
> match the commit of the tag (34a083b) and are therefore obsolete.

is that the FreeCAD team don't bother archiving the sources by
themselves, given that one can always access the latest version
on GitHub.

-
Sergiu

Re: Appimage: cannot run binary file

[Christophe Pisteur]

Le jeudi 11 février 2021 à 15:12 +0100, Sergiu Ivanov a écrit :
> Hi Christophe,
> > I don't understand all the nuances of this discussion (I'm sorry),
> > butit seems to me that the problem is, in the case of the
> > developmentversion of freecad, that the sources are not published
> > regularly. Thesources were last published in 2019 (1), while
> > freecad offers anAppimage almost every week. So building something
> > from the sources ofthe development code doesn't add much value to
> > the stable version. Imust certainly be missing something, so once
> > again sorry.Christophe(1) 
> > https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre: "
> > Note:The development binaries are built regularly (You may need to
> > expandthe assets tab) . The release date indicates the beginning of
> > the devcycle. The commits indicates how many commits in the dev
> > cycle. Thesource archives (tar.gz and .zip) do not get updated, so
> > they match thecommit of the tag (34a083b) and are therefore
> > obsolete. You can get thelatest source here: 
> > https://github.com/FreeCAD/FreeCAD/archive/master.zip"
> 
> I don't know or use FreeCAD, but it looks like the source code
> isupdated quite regularly on their GitHub repository:
>   https://github.com/FreeCAD/FreeCAD/
> 
> The latest changes seem to date back to several hours.
> I'd say these are the sources from which the development binaries
> arebuilt (at least this is what is usually done).
> My understanding of the sentence
> > The source archives (tar.gz and .zip) do not get updated, so
> > theymatch the commit of the tag (34a083b) and are therefore
> > obsolete.
> 
> is that the FreeCAD team don't bother archiving the sources
> bythemselves, given that one can always access the latest versionon
> GitHub.
> -Sergiu

Sorry for the confusion and thank you for the explanation. 
Christophe

Re: Appimage: cannot run binary file

[raingloom]

On Thu, 11 Feb 2021 15:43:24 +0100
Christophe Pisteur <christophe.pisteur@fsfe.org> wrote:

> Le jeudi 11 février 2021 à 15:12 +0100, Sergiu Ivanov a écrit :
> > Hi Christophe,  
> > > I don't understand all the nuances of this discussion (I'm sorry),
> > > butit seems to me that the problem is, in the case of the
> > > developmentversion of freecad, that the sources are not published
> > > regularly. Thesources were last published in 2019 (1), while
> > > freecad offers anAppimage almost every week. So building something
> > > from the sources ofthe development code doesn't add much value to
> > > the stable version. Imust certainly be missing something, so once
> > > again sorry.Christophe(1) 
> > > https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre: "
> > > Note:The development binaries are built regularly (You may need to
> > > expandthe assets tab) . The release date indicates the beginning
> > > of the devcycle. The commits indicates how many commits in the dev
> > > cycle. Thesource archives (tar.gz and .zip) do not get updated, so
> > > they match thecommit of the tag (34a083b) and are therefore
> > > obsolete. You can get thelatest source here: 
> > > https://github.com/FreeCAD/FreeCAD/archive/master.zip"  
> > 
> > I don't know or use FreeCAD, but it looks like the source code
> > isupdated quite regularly on their GitHub repository:
> >   https://github.com/FreeCAD/FreeCAD/
> > 
> > The latest changes seem to date back to several hours.
> > I'd say these are the sources from which the development binaries
> > arebuilt (at least this is what is usually done).
> > My understanding of the sentence  
> > > The source archives (tar.gz and .zip) do not get updated, so
> > > theymatch the commit of the tag (34a083b) and are therefore
> > > obsolete.  
> > 
> > is that the FreeCAD team don't bother archiving the sources
> > bythemselves, given that one can always access the latest versionon
> > GitHub.
> > -Sergiu  
> 
> Sorry for the confusion and thank you for the explanation. 
> Christophe

My bad, I didn't consider that not everyone knows Git.
This is probably the example you need:
guix build freecad --with-git-url=freecad=https://github.com/FreeCAD/FreeCAD/
No need to download any tarballs this way.

Re: Appimage: cannot run binary file

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

On Fri, Feb 12, 2021 at 06:12:52AM +0100, raingloom wrote:
> On Thu, 11 Feb 2021 15:43:24 +0100
> Christophe Pisteur <christophe.pisteur@fsfe.org> wrote:
> 
> > Le jeudi 11 février 2021 à 15:12 +0100, Sergiu Ivanov a écrit :
> > > Hi Christophe,  
> > > > I don't understand all the nuances of this discussion (I'm sorry),
> > > > butit seems to me that the problem is, in the case of the
> > > > developmentversion of freecad, that the sources are not published
> > > > regularly. Thesources were last published in 2019 (1), while
> > > > freecad offers anAppimage almost every week. So building something
> > > > from the sources ofthe development code doesn't add much value to
> > > > the stable version. Imust certainly be missing something, so once
> > > > again sorry.Christophe(1) 
> > > > https://github.com/FreeCAD/FreeCAD/releases/tag/0.19_pre: "
> > > > Note:The development binaries are built regularly (You may need to
> > > > expandthe assets tab) . The release date indicates the beginning
> > > > of the devcycle. The commits indicates how many commits in the dev
> > > > cycle. Thesource archives (tar.gz and .zip) do not get updated, so
> > > > they match thecommit of the tag (34a083b) and are therefore
> > > > obsolete. You can get thelatest source here: 
> > > > https://github.com/FreeCAD/FreeCAD/archive/master.zip"  
> > > 
> > > I don't know or use FreeCAD, but it looks like the source code
> > > isupdated quite regularly on their GitHub repository:
> > >   https://github.com/FreeCAD/FreeCAD/
> > > 
> > > The latest changes seem to date back to several hours.
> > > I'd say these are the sources from which the development binaries
> > > arebuilt (at least this is what is usually done).
> > > My understanding of the sentence  
> > > > The source archives (tar.gz and .zip) do not get updated, so
> > > > theymatch the commit of the tag (34a083b) and are therefore
> > > > obsolete.  
> > > 
> > > is that the FreeCAD team don't bother archiving the sources
> > > bythemselves, given that one can always access the latest versionon
> > > GitHub.
> > > -Sergiu  
> > 
> > Sorry for the confusion and thank you for the explanation. 
> > Christophe
> 
> My bad, I didn't consider that not everyone knows Git.
> This is probably the example you need:
> guix build freecad --with-git-url=freecad=https://github.com/FreeCAD/FreeCAD/
> No need to download any tarballs this way.

Note that the first time will take a while to clone the repository, then
it will get on to building.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]