New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 679858 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 405595
issue 765499
issue 765753

Blocking:
issue 788213
issue 676152



Sign in to add a comment

flashrom/mosys should not be static

Project Member Reported by vapier@chromium.org, Jan 10 2017

Issue description

we made these programs static because of https://crosbug.com/p/11630, and it was only as a hack because static programs "seemed to work".  unfortunately, we're running low on space, and these static programs are not small.  we need to reclaim this space.
 

Comment 1 by hungte@chromium.org, Jan 11 2017

How much space can we get by making flashrom / mosys dynamic?

Comment 2 by vapier@chromium.org, Jan 11 2017

almost 2MB on x86_64

dynamic:
  687920 flashrom
  558488 mosys

static:
  1675352 flashrom
  1336144 mosys
Cc: -dhend...@chromium.org pgeorgi@chromium.org
Owner: martinroth@chromium.org
Status: Assigned (was: Unconfirmed)
We did make flashrom static because it is executed during a system update, and thus might not have the right dynamic libraries available. Can we re-evaluate this?
Cc: wnhuang@chromium.org
Owner: ----
Status: Available (was: Assigned)
The problem here looks like it was only with the flashrom / mosys that are shipped as part of an autoupdate.  There's no reason to statically link flashrom / mosys on a normal system nor on a recovery image.

Comment 6 by vapier@chromium.org, Sep 14 2017

Blockedon: 405595
thanks for pointing that out, i missed that nuance when reading the other bug report.  yes, if flashrom/mosys are run as part of post install, we can run into issues of runtime libs mismatching, and static linking probably works around most of the issues (although it isn't a fix for all).

unfortunately, making that better is a bit of a yak shave:  issue 405595 .  we want to stop forcing programs to be statically linked just to be used in AU and instead switch them to a stripped runtime (like our initramfs) via lddtree.

due to the way we build things currently though, it isn't possible to produce two copies of the programs (one statically and one dynamically linked) unless we either duplicate the ebuild (and install them in diff places), or we change the ebuild to produce both (and install them in diff places).  both routes kind of suck.
Ick.  Yeah, I was just thinking about how to possibly solve that and that was what I was starting to decide.  ...I guess there's the third option of doing something like "emerge_custom_kernel" in "common.sh", but that's probably equally ugly too...
Cc: sjg@chromium.org teravest@chromium.org
Labels: Hotlist-GoodFirstBug
Maybe a task someone in Boulder might want to look at as a starter project?  Or is it too tricky?

Comment 9 by sjg@chromium.org, Sep 14 2017

Gosh, this seems like it would be better on Hotlist-BadFirstBug

That said there is some relation with firmware update which I have meddled with. How would you judge the priority of this?
Labels: -Hotlist-GoodFirstBug Hotlist-BadFirstBug
Hard to say.  At the moment it's causing problems with  bug #764753 , but hopefully we can find another way to mitigate that for now...
Blockedon: 765753
Blocking: 788213
Owner: jclinton@chromium.org
I will do this as we flip mosys over to a Rust/C hybrid dynamically linked binary.
Blockedon: 765499
Now that lddtree is in, I think we get rid of mosys_s. Did we switch to --root everywhere?

not yet. one more CL.
Project Member

Comment 17 by bugdroid1@chromium.org, May 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/7900ec8046bc05cb7985342301f2a80fb605bd7c

commit 7900ec8046bc05cb7985342301f2a80fb605bd7c
Author: Samantha Miller <samanthamiller@google.com>
Date: Wed May 30 19:50:57 2018

mosys: Modify mosys build to remove static option

BUG= chromium:679858 
TEST=built and ran on board

Change-Id: I8e4571d90c512b2a0303fe30c22f3839be09598a
Reviewed-on: https://chromium-review.googlesource.com/1072237
Commit-Ready: Samantha Miller <samanthamiller@google.com>
Tested-by: Samantha Miller <samanthamiller@google.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>

[modify] https://crrev.com/7900ec8046bc05cb7985342301f2a80fb605bd7c/sys-apps/mosys/mosys-9999.ebuild

Project Member

Comment 18 by bugdroid1@chromium.org, May 31 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/1d40452ecc61f21f23cfd2de0d34bb59e987f7eb

commit 1d40452ecc61f21f23cfd2de0d34bb59e987f7eb
Author: Mike Frysinger <vapier@chromium.org>
Date: Thu May 31 19:26:17 2018

mosys: drop mosys_s mask

We don't build mosys_s anymore, and we install it in firmware builds
dynamically, so no need for this mask anymore.

BUG= chromium:679858 
TEST=precq passes

Change-Id: I25d70e75186f30a9b363645bbc115b8542979e72
Reviewed-on: https://chromium-review.googlesource.com/1079831
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>

[delete] https://crrev.com/4e18f030d0e15f611a06c3d26b5c3c7d68fad30e/chromeos/config/env/sys-apps/mosys

Project Member

Comment 19 by bugdroid1@chromium.org, May 31 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/mosys/+/38b881ff3508bd536dfd06da54ea6f51212a709e

commit 38b881ff3508bd536dfd06da54ea6f51212a709e
Author: Samantha Miller <samanthamiller@google.com>
Date: Thu May 31 19:26:14 2018

mosys: Convert mosys to only produce shared library

BUG= chromium:679858 
TEST=built and ran board and firmware update succeeds
CQ-DEPEND=CL:I8e4571d90c512b2a0303fe30c22f3839be09598a

Change-Id: I34e43aea84ca9b852df0221dfd05b3bae9de1bdd
Reviewed-on: https://chromium-review.googlesource.com/1072368
Commit-Ready: Samantha Miller <samanthamiller@google.com>
Tested-by: Samantha Miller <samanthamiller@google.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>

[modify] https://crrev.com/38b881ff3508bd536dfd06da54ea6f51212a709e/README
[modify] https://crrev.com/38b881ff3508bd536dfd06da54ea6f51212a709e/build.rs
[modify] https://crrev.com/38b881ff3508bd536dfd06da54ea6f51212a709e/meson_options.txt
[modify] https://crrev.com/38b881ff3508bd536dfd06da54ea6f51212a709e/meson.build

Project Member

Comment 20 by bugdroid1@chromium.org, Jun 6 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/5e4772b6b1e04492367bc869bf8d31cf0c9df65a

commit 5e4772b6b1e04492367bc869bf8d31cf0c9df65a
Author: Mike Frysinger <vapier@chromium.org>
Date: Wed Jun 06 08:16:22 2018

flashrom: drop static flashrom_s

Now that the various updaters use lddtree to get dynamic binaries,
there's no need to build static flashrom_s anymore.

Also clean up the src_test func in flashrom.  The "tests.py" file
hasn't existed for over a year.

BUG= chromium:679858 
TEST=precq passes

Change-Id: I00d7df01d6eadf69ba2157a93bf855cabfe11fd8
Reviewed-on: https://chromium-review.googlesource.com/1079757
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>

[delete] https://crrev.com/162c6663204ac66f0d99c0ccba83636b1c6921f3/chromeos/config/env/sys-apps/flashrom
[modify] https://crrev.com/5e4772b6b1e04492367bc869bf8d31cf0c9df65a/profiles/default/linux/package.use
[modify] https://crrev.com/5e4772b6b1e04492367bc869bf8d31cf0c9df65a/profiles/features/cros-factory-server/package.use
[modify] https://crrev.com/5e4772b6b1e04492367bc869bf8d31cf0c9df65a/sys-apps/flashrom/flashrom-9999.ebuild
[modify] https://crrev.com/5e4772b6b1e04492367bc869bf8d31cf0c9df65a/profiles/targets/chromeos/package.use

Status: Fixed (was: Available)
Both mosys and flashrom are not static now so I think this is fixed?
Components: Infra>Client>ChromeOS>Build

Sign in to add a comment