all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Jonathan Frederickson <jonathan@terracrypt.net>
Cc: 35591@debbugs.gnu.org
Subject: bug#35591: Segfault on flatpak remote-add
Date: Sun, 05 May 2019 18:36:06 -0400	[thread overview]
Message-ID: <87muk0sf4e.fsf@netris.org> (raw)
In-Reply-To: <12034386-e609-4dec-997f-bbf6614d8482@www.fastmail.com> (Jonathan Frederickson's message of "Sun, 05 May 2019 16:05:25 -0400")

Hi Jonathan,

"Jonathan Frederickson" <jonathan@terracrypt.net> writes:
> I'm attempting to use Flatpak on my Guix system, and I'm experiencing
> segfaults when attempting to add a remote repo. Provided below are the
> output of the command I'm attempting to run, as well as some info
> about my system.

My knowledge of Flatpak is weak, but in general, foreign pre-compiled
binaries will not work on Guix unless they are statically linked.
Traditional dynamically-linked executables expect to find a dynamic
linker and system shared libraries in /lib or /lib64, which do not exist
on a Guix system.  It is also fairly common for foreign binaries to
depend on standard files and programs in /usr, /bin, and /sbin, none of
which are present on a Guix system except for /bin/sh.

Having said that, if you must run foreign pre-compiled binaries on Guix,
there are various hacks to do it.  One approach is to install symlinks
in /lib*, /usr, /bin, /sbin, etc, pointing to the needed components in
/run/current-system.  Another is to modify the pre-compiled binaries to
look for components in the right place using 'patchelf'.  We use the
latter approach to bootstrap GHC (Glasgow Haskell Compiler), which can
only be compiled by itself.

I'm sorry I don't have a better answer for you, but Guix was not
designed to run foreign pre-compiled binaries.  If that's important to
you, it might be that Guix is not a good fit for you.

However, if your goal is to run Guix-compiled programs in a sandbox,
that's something we are certainly very interested in, and we could use
help.  We have "guix container" as a building block, and I know that
some Guix users have experimented with running e.g. GNU IceCat within a
container.  I don't know the current status of those efforts.  Hopefully
someone more knowledgable in this area will chime in.

     Regards,
       Mark

  reply	other threads:[~2019-05-05 22:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-05 20:05 bug#35591: Segfault on flatpak remote-add Jonathan Frederickson
2019-05-05 22:36 ` Mark H Weaver [this message]
2019-05-05 22:47   ` Jonathan Frederickson
2019-10-31 10:50 ` Ben Sturmfels
2020-05-11 20:23   ` Ricardo Wurmus
2020-05-11 21:38     ` Ricardo Wurmus
2020-05-14  5:26       ` Ricardo Wurmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muk0sf4e.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=35591@debbugs.gnu.org \
    --cc=jonathan@terracrypt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.