boringssl is built with cmake, but, for cross-compiling it requires that the CMAKE_SYSTEM_PROCESSOR variable be set.  This variable is not set by the version of cmake-utils.eclass in portage-stable.  This was fixed in upstream gentoo by:

commit d9b6edbeec026d8f63ed278854526eebd5fb30e5 cmake-utils.eclass: set CMAKE_SYSTEM_PROCESSOR, certain buildsystems rely on this for crosscompiling. Patch by aballier,  bug 607904 

However, updating to the latest cmake-utils.eclass:
 (a) requires adding new ninja-utils.eclass
 (b) requires updating the following packages due to cmake-util's new EAPI >= 5 requirement:
   libftdi-1.0-r4
   libdivsufsort-2.0.1
   opencv-2.3.0-r6
   mariadb-5.5.32-r7

patches to update the packages in #1 to EAPI=5:

dev-embedded/libftdi:     https://chromium-review.googlesource.com/536398
dev-libs/libdivsufsort:   https://chromium-review.googlesource.com/538452
media-libs/opencv:        https://chromium-review.googlesource.com/536726
dev-db/mariadb:           https://chromium-review.googlesource.com/536542

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

commit 94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri Jun 16 08:49:30 2017

dev-embedded/libftdi: Update to latest from gentoo

Update to the latest libftdi from upstream gentoo - with the following
caveats:
 * Keep EAPI=5; this ebuild does not use any EAPI=6 features
 * Remove python3_6 from PYTHON_COMPAT
 * Keep KEYWORDS="*"
 * Add blocker to force portage to migrate to keep upstream's SLOT=1
 * Apply (rebased) 1.2-getopts.patch
 * Install confs/*.conf

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium:733477
TEST=emerge-soraka libftdi

Change-Id: I9c99a5718e94643ac4bf3089779551c8dc5e7f49
Reviewed-on: https://chromium-review.googlesource.com/536398
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[delete] https://crrev.com/64c9b5085b2e40435aab12be5861d640222edb1a/dev-embedded/libftdi/libftdi-1.0.ebuild
[modify] https://crrev.com/94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e/dev-embedded/libftdi/metadata.xml
[delete] https://crrev.com/64c9b5085b2e40435aab12be5861d640222edb1a/dev-embedded/libftdi/libftdi-1.0-r4.ebuild
[add] https://crrev.com/94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e/dev-embedded/libftdi/libftdi-1.2.ebuild
[delete] https://crrev.com/64c9b5085b2e40435aab12be5861d640222edb1a/dev-embedded/libftdi/files/libftdi-1.0-staticlibs.patch
[modify] https://crrev.com/94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e/dev-embedded/libftdi/Manifest
[rename] https://crrev.com/94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e/dev-embedded/libftdi/files/libftdi-1.2-getopts.patch
[add] https://crrev.com/94ca1a21c4e3dab1a0ad305204bc3aed7fdf310e/dev-embedded/libftdi/libftdi-1.2-r2.ebuild

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

commit 64c9b5085b2e40435aab12be5861d640222edb1a
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri Jun 16 08:49:28 2017

dev-db/mariadb: Update EAPI to 5

maridb uses cmake-utils.  The latest upstream cmake-utils.eclass requires
EAPI >= 5.  This ebuild is already conforms to EAPI 5, so just bump the
EAPI.

This package appears to only be used by moblab, and has had pretty
significant chromium specific modification, so an upgrade to the latest
upstream version is beyond the scope of this fix.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium:733477
TEST=emerge-guado_moblab mariadb
 => builds ok

Change-Id: Ib6fa7e455c1b2fce0b1a1555e8a5349c699bbf74
Reviewed-on: https://chromium-review.googlesource.com/536542
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[rename] https://crrev.com/64c9b5085b2e40435aab12be5861d640222edb1a/dev-db/mariadb/mariadb-5.5.32-r8.ebuild
[modify] https://crrev.com/64c9b5085b2e40435aab12be5861d640222edb1a/dev-db/mariadb/mariadb-5.5.32.ebuild

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/b2b70ae19f5cf6635b6876bf475a052f65d50dbd

commit b2b70ae19f5cf6635b6876bf475a052f65d50dbd
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri Jun 16 08:49:28 2017

dev-cpp/eigen: Import latest stable from gentoo

The latest stable opencv from upstream gentoo now builds with eigen
support by default.  So, let's import latest stable eigen ebuild from
upstream gentoo.

Notes:
 * Set EAPI to 5
 * Set KEYWORDS to "*"

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium:733477
TEST=emerge-soraka eigen
  => built properly from this ebuild
TEST=emerge-hana eigen
  => built properly from this ebuild

Change-Id: I1b4bdfbe711173b97d5437b439d8d0efeefc255f
Reviewed-on: https://chromium-review.googlesource.com/536725
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[add] https://crrev.com/b2b70ae19f5cf6635b6876bf475a052f65d50dbd/dev-cpp/eigen/files/eigen-3.2.7-pastix-5.2-backport.patch
[add] https://crrev.com/b2b70ae19f5cf6635b6876bf475a052f65d50dbd/dev-cpp/eigen/Manifest
[add] https://crrev.com/b2b70ae19f5cf6635b6876bf475a052f65d50dbd/dev-cpp/eigen/files/eigen-3.2.7-adaolc-backport.patch
[add] https://crrev.com/b2b70ae19f5cf6635b6876bf475a052f65d50dbd/dev-cpp/eigen/eigen-3.2.8-r2.ebuild
[add] https://crrev.com/b2b70ae19f5cf6635b6876bf475a052f65d50dbd/dev-cpp/eigen/metadata.xml

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

commit 58acf434af565bbb5bdf4ac55a7d730d89830ed5
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Sun Jun 18 22:08:13 2017

dev-libs/libdivsufsort: Re-sync with upstream gentoo

The latest upstream cmake-utils.eclass has a strict requirement for all
inheriting ebuilds to use EAPI >= 5.

The libdivsufsort build uses cmake-utils, but its current ebuild uses
EAPI=3.  Let's take this opportunity to resync with latest upstream
gentoo ebuild.

The upstream gentoo ebuild for libdivsufsort has an equivalent fix as
what we have in chromiumos-overlay for fixing up the lib directory, so
we can drop the local patch.

However, we also maintain a not-upstream change to enable the 64-bit
build of libdivsufsort, which is a dependency of dev-util/bsdiff, so we
can't just move back to a vanilla portage-stable ebuild.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG=chromium:733477
TEST=emerge-soraka libdivsufsort
  => built ok
TEST=equery-soraka files libdivsufsort
  => includes:
     /usr/include/divsufsort64.h
     /usr/lib64/libdivsufsort.so.3.0.0
TEST=emerge-soraka bsdiff
  => builds ok

Change-Id: I1cbd454157854565f9c1e64635f0b35db669b400
Reviewed-on: https://chromium-review.googlesource.com/538452
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[add] https://crrev.com/58acf434af565bbb5bdf4ac55a7d730d89830ed5/dev-libs/libdivsufsort/libdivsufsort-2.0.1-r1.ebuild
[modify] https://crrev.com/58acf434af565bbb5bdf4ac55a7d730d89830ed5/dev-libs/libdivsufsort/libdivsufsort-2.0.1.ebuild
[delete] https://crrev.com/d92d40740608aa4d5f00237e99276954867cdccd/dev-libs/libdivsufsort/files/libdivsufsort-2.0.1-libsuffix.patch

I haven't made much progress on BoringSSL in a long time.

Here is what I had done, for the simple use case of building a static BoringSSL library and linking it in to a single executable (eg., for usb_updater2 from the chromeos-ec package):

(1) an ebuild that builds a static library that can be used by another package:
https://chromium-review.googlesource.com/#/c/chromiumos/overlays/chromiumos-overlay/+/535258/

(2) CL (1) requires fixes to cmake & opencv:
https://chromium-review.googlesource.com/#/c/chromiumos/overlays/portage-stable/+/535414/
https://chromium-review.googlesource.com/#/c/chromiumos/overlays/portage-stable/+/536726/

(3) a CL showing how to link in the resulting boringssl .a:
https://chromium-review.googlesource.com/#/c/chromiumos/platform/ec/+/535198/

Presumably, a full-scale switch to BoringSSL would require modifications to a similar list of packages.
However, the first task would be to just convert the chromeos-base packages to BoringSSL first.