mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "A. Wilcox" <awilfox@adelielinux.org>
To: musl@lists.openwall.com
Subject: Re: Re: Adapting binaries easily to musl, or database with binaries (musl)
Date: Sun, 9 Jun 2019 10:01:12 -0500	[thread overview]
Message-ID: <558d41bf-5d1a-aacd-9185-d15fefdf1d85@adelielinux.org> (raw)
In-Reply-To: <CAHCeaGNp5j0Hm=Smd7SzsBoF3oWnQEvsvtmPipvmowP5xj4Ykg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4085 bytes --]

On 06/09/19 09:10, Brian Peregrine wrote:
> I've been trying to get firefox musl (from
> https://distfiles.adelielinux.org/adelie/1.0-beta3/user/pmmx/ )
> started (haven't gotten much further then a XPCOMGlueLoad error so
> far). Regardless of this, I did notice that the firefox version is
> 52.9.0-r4 whereas we're currently at version 67, so not sure whether
> that's recent enough for github.


It's still recent enough for GitHub so far.  We won't be bumping to 60
due to CPU incompatibilities ( https://bugzilla.mozilla.org/1499121 ).

We hope to have 68 available soon after it is released.


> I'm also thinking whether this is really the best approach or not.
> 
> One alternative could be to just download the ebuild from portage, and
> then compile it for musl i686 to a usb stick (main reason for putting
> the files to a usb stick is that TAZ is a livecd so you can only store
> files for a limited duration -any files not stored on removable media
> are erased at reboot). After saving the files to the usb stick, the
> user would start the program from the usb stick (so not copying the
> files manually to the system; reason is that it's easier to not copy
> the files every time and the system itself is read-only, no copying to
> the system is permitted)
> 
> I don't know however whether
> * ebuilds from portage can be compiled under musl at all


Adélie started life four years ago as a Gentoo fork with binpkgs.  There
are a few overlays:

https://gitweb.gentoo.org/proj/musl.git/

https://github.com/smaeul/portage-overlay/

The second one actually has a pretty good Chromium patchset, much higher
quality than the others I've seen.  (I still wouldn't advise running
Chromium on low-end hardware, or anywhere that security or privacy
matter, but at least it won't wreck itself over musl with these patches.)


> * whether the files saved this way can actually be started from usb
> stick (I doubt the files thus obtained by this method qualify as a
> "binary")


As long as the compilation flags are generic enough, it is exactly how
binaries are generated in any other project.


> * whether compiling programs using portage is leaner (less cpu/ram
> intensive) then compiling the programs from (github) source (assuming
> there is a difference at all). This is important as since it's a live
> cd, it is already ram-intensive and we also focus on low-spec machines
> (starting from i686)


There isn't a large difference, but using the musl overlays and the
Gentoo tree, you at least have a semi-decent chance of building without
any errors, as you will have the patches already put in.

Do note that Firefox requires at least 4 GB RAM with "lots of swap", and
at least 6 GB disk space:

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Linux_Prerequisites

Now that it uses Rust (since version 58, IIRC), if you are on a source
distribution like Gentoo you will have to build Rust as well.  Rust is
very hard to build on musl (you *need* to use the overlays above), and
needs a lot of time and RAM/CPU.  For a specific example, the Adélie
builder for x86 is a 12-core Xeon system with 24 GB RAM.  It takes about
three hours to build Rust.


> Another possible way is to use anbox on gentoo and run the android
> versions of the programs (which can be found easily at the app store)
> directly (so not through installation with APK Tools). I don't know
> however whether this would run at all under gentoo musl and it's
> probably also overkill (as anbox, adb, ... need to be installed and
> the android programs might also not be stable even if they do run)


In addition to those issues, Firefox for Android takes a lot more RAM
than desktop Firefox (which is already a large amount; it barely runs in
512 MB here).  I wouldn't recommend that, though if you wanted to try
porting anbox to musl, I'm sure that'd be appreciated by the community.

-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


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

      reply	other threads:[~2019-06-09 15:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08  9:33 Brian Peregrine
2019-06-08 10:51 ` Szabolcs Nagy
2019-06-09 14:10   ` Brian Peregrine
2019-06-09 15:01     ` A. Wilcox [this message]

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=558d41bf-5d1a-aacd-9185-d15fefdf1d85@adelielinux.org \
    --to=awilfox@adelielinux.org \
    --cc=musl@lists.openwall.com \
    /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 public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).