Gentoo emerge: Failed Running automake

This article is for Gentoo build problem:

Failed Running automake

but basically the problem could occur in any Linux system and the solution is logically the same.
During our @world update our emerge failed on:

>>> Emerging (44 of 95) dev-libs/libmemcached-1.0.18-r3::gentoo
 * libmemcached-1.0.18.tar.gz BLAKE2B SHA512 size 😉 ...                                                                                                            [ ok ]
>>> Unpacking source...
>>> Unpacking libmemcached-1.0.18.tar.gz to /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work
>>> Preparing source in /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18 ...
 * Applying debug-disable-enable-1.0.18.patch ...                                                                                                                    [ ok ]
 * Applying continuum-1.0.18.patch ...                                                                                                                               [ ok ]
 * Applying libmemcached-1.0.18-gcc7.patch ...                                                                                                                       [ ok ]
 * Running eautoreconf in '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18' ...
 * Running libtoolize --install --copy --force --automake ...                                                                                                        [ ok ]
 * Running aclocal -I m4 -I libtest/m4 ...                                                                                                                           [ ok ]
 * Running autoconf --force ...                                                                                                                                      [ ok ]
 * Running autoheader ...                                                                                                                                            [ ok ]
 * Running automake --add-missing --copy --foreign --force-missing ...                                                                                               [ !! ]

 * Failed Running automake !
 * 
 * Include in your bugreport the contents of:
 * 
 *   /var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/automake.out

 * ERROR: dev-libs/libmemcached-1.0.18-r3::gentoo failed (prepare phase):
 *   Failed Running automake !
 * 
 * Call stack:
 *     ebuild.sh, line  124:  Called src_prepare
 *   environment, line 2214:  Called eautoreconf
 *   environment, line  714:  Called eautomake
 *   environment, line  668:  Called autotools_run_tool 'automake' '--add-missing' '--copy' '--foreign' '--force-missing'
 *   environment, line  532:  Called die
 * The specific snippet of code:
 *           die "Failed Running $1 !";
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/libmemcached-1.0.18-r3::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/libmemcached-1.0.18-r3::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18'
 * S: '/var/tmp/portage/dev-libs/libmemcached-1.0.18-r3/work/libmemcached-1.0.18'

>>> Failed to emerge dev-libs/libmemcached-1.0.18-r3, Log file:

We have installed automake, the dependency is OK, there is no need of new version of automake (the libmemcached did not required to install a new version as a dependency), but still the build process failed!
automake has many different versions installed on the same system and the problem is that one of your currently installed version is too old, so you must upgrade all versions (from the all different branches installed).
First check what versions are installed (equery is part of app-portage/gentoolkit):

root@srv ~ # equery list automake
 * Searching for automake ...
[I--] [??] sys-devel/automake-1.11.3:1.11
[I--] [??] sys-devel/automake-1.12.6:1.12
[I--] [??] sys-devel/automake-1.13.4:1.13
[I--] [??] sys-devel/automake-1.14.1:1.14
[IP-] [  ] sys-devel/automake-1.15.1-r2:1.15
[IP-] [  ] sys-devel/automake-1.16.1-r1:1.16

We have version from branch 1.11, 1.12, 1.13 and 1.14 – one of these version is causing the problem!
Up until now no package required as a dependency 1.15 and 1.16, so we do not have it installed.

Here we upgrade them all to their latest versions in every branch version:

root@srv ~ # emerge -vu sys-devel/automake:1.11 sys-devel/automake:1.12 sys-devel/automake:1.13 sys-devel/automake:1.14

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] sys-devel/automake-1.12.6-r2:1.12::gentoo [1.12.6:1.12::gentoo] USE="-test%" 1368 KiB
[ebuild     U  ] sys-devel/automake-1.11.6-r3:1.11::gentoo [1.11.3:1.11::gentoo] USE="-test%" 896 KiB
[ebuild     U  ] sys-devel/automake-1.14.1-r2:1.14::gentoo [1.14.1:1.14::gentoo] USE="-test%" 1455 KiB
[ebuild     U  ] sys-devel/automake-1.13.4-r2:1.13::gentoo [1.13.4:1.13::gentoo] USE="-test%" 1416 KiB

Total: 4 packages (4 upgrades), Size of downloads: 5133 KiB

As you can see we have updated version in every branch! And after updating them the building of libmemcached passed smoothly!
It’s not only in Gentoo, in most Linux distros (such as Ubuntu, CentOS, Manjaro, Mint and so on) have multiple automake version installed, so if you encounter this problem check your automake version installed for their latest versions and also if you miss some of them.

Manual install of base Gentoo Linux x86_64 with openrc (init) and uefi using minimal installation cd

Here we are going to show the minimum steps to install a base Gentoo Linux on your computer – server or desktop using “Minimal Installation CD”.
The installation ISO CD is generated on 11.09.2018, but you can use an older or newer one, this guide uses commands, which are available in really old ISOs (10 years ago) and probably will be available in the future, too! The idea is not to change this ISO a lot and to have only the basic tools for installation, which should be the same for a really log time! If you need more tools there two other options: Hybrid IS0, which is a LiveDVD – a system with GUI and Admin CD, which is extended version of the minimal installation CD (no GUI).

Our base Gentoo system will use:

  1. OpenRC, which is based on init to boot the server. This is the default in Gentoo, but you might have problems using Gnome
  2. GRUB 2 UEFI enabled and the server will be booted in UEFI mode. Recently most of the desktop machine and server support it and in many cases it is mandatory to use a new hardware.
  3. No GUI will be installed (KDE, Gnome, Xfce and so on), there are other tutorials for this, you can check here (coming soon)

Keep on reading!

Gentoo Minimal Installation CD (amd64 aka x86_64) – booting (in UEFI mode)

Here is the process of booting from a Gentoo Minimal Installation CD amd64 (x86_64) with UEFI mode enabled. This is not an installation guide!
You can download the CD from here: https://www.gentoo.org/downloads/ Here is the ISO file: http://distfiles.gentoo.org/releases/amd64/autobuilds/20180911T214502Z/install-amd64-minimal-20180911T214502Z.iso or you can check it in some mirror like leaseweb – http://mirror.leaseweb.com/gentoo/releases/amd64/autobuilds/current-install-amd64-minimal/install-amd64-minimal-20180911T214502Z.iso.

Our motherboard is Asus ROG Zenith Extreme motherboard using X399 chipset https://www.asus.com/th/Motherboards/ROG-ZENITH-EXTREME/ and you’ll see the BIOS options for it, but they do not differ much with the other motherboard boot options. Here also setup the network and start up an openssh server to manage our Gentoo Linux installation – (coming soon).

SCREENSHOT 1) Starting the machine

main menu
Start up

Keep on reading!

Gentoo update tips when updating packages with blocks and masked files

It’s not so rear to have

blocks or masked files

when using Gentoo emerge system, but it is not complex and in most cases it is easy to resolve

To summarize it up at the beginning and then we are going to show you other articles using these advises here where you’ll see what are the steps we took to resolve the conflicts and masked packages:

  • Use verbose,verbose-conflicts and backtrack with emerge
  • Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
  • Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
  • Do not update everything with one line, you could update only the base libraries like QT, which are very important for the Linux GUI in general
  • Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.
  • use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
  • Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
  • In rear cases you can use “–nodeps” when updating or installing a new package (we do not need and show this one here!)
  • Do NOT rebuild the entire system with “emerge -v world” every time when you rebuild glibc, gcc, it is not mandatory to do it to have a healthy system.
  • Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
  • use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
    emerge -v $(qlist -IC|grep <NAME>)
    

    and for update just add “u” to “-v”:

    emerge -vu $(qlist -IC|grep <NAME>)
    

Keep on reading!

Gentoo updating KDE – package blocks

In continuing our tips for updating big or multiple packages in Gentoo this time we show how to update KDE Platform, Plasma and Apps packages. In Gentoo KDE Desktop GUI is split into three major categories:

  1. kde-frameworks
  2. kde-plasma
  3. kde-apps

How we managed to update in our current situation:

  1. Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
  2. use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
  3. Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!

More on the subject of update tips here: Gentoo update tips when updating packages with blocks and masked files
Keep on reading!

Gentoo updating perl with many masked and blocked packages

After our previous howto Gentoo – update dev-libs/icu on a desktop box with KDE GUI and many masked packages we want to show you another example of how to update perl, which could have hundreds dependencies installed as perl modules. You can check for more details above howto, details about what to do when there are masked and blocked packages, because here we use only some of the options we have the proper ones for this case.
Just to note when updating perl you must reinstall (recompile, rebuild) all the external modules (additional packages) and all perl modules installed with CPAN module (if you do not know what is this, you probably have not used it so no worries).

How we managed to update in our current situation:

  • use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
  • Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
  • Use verbose,verbose-conflicts and backtrack with emerge
  • Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.

More on the subject of update tips here: Gentoo update tips when updating packages with blocks and masked files
Keep on reading!

Gentoo – update dev-libs/icu on a desktop box with KDE GUI and many masked packages

No, we are not going to answer why someone will use Gentoo for Desktop, but well such human beings still exist and we have one piece of snippet the updating old dev-libs/icu packet, because KDE Platform and new version of Chromium depend on a new version >=dev-libs/icu-59.
The main reason to include this update here is show how to deal with the dependency hell in Gentoo – multiple blocked packages and some old and deprecated packages, but still installed.

To summarize it up at the beginning how we did it

and then you’ll see what are the steps we took to resolve the conflicts and masked packages:

  • Use verbose,verbose-conflicts and backtrack with emerge
  • Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
  • Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
  • Include explicitly packages, which block our updates in the emerge line!
  • use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
  • Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.

More on the subject of update tips here: Gentoo update tips when updating packages with blocks and masked files
Keep on reading!

vmware-modules failed with too many arguments to function smp_call_function and smp_call_function_single

vmware-modules is really tough to compile on a bleeding edge kernel like last versions from kernel.org When a new kernel is out the chances you cannot vmware modules are really big and if you look at the patches a gentoo build applies at present 40 (at the end you can see a log from Gentoo) an almost all begin with

kernel_version-[why_is_needed].patch

But apparently not only the patches are needed the CFLAGS are also important. And if you include

-fomit-frame-pointer in CFLAGS/CXXFLAGS

you’ll get into troubles! And this is not specific to Gentoo and probably not to specific kernel version, because there are reports from 2012 and before 2012! So if you have the following error:

In file included from /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:69:0:
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c: In function ‘LinuxDriverEstimateTSCkHz’:
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/vmmonInt.h:88:15: error: too many arguments to function ‘smp_call_function_single’
               smp_call_function_single(cpu, fn, info, 1, wait)
               ^
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:208:10: note: in expansion of macro ‘compat_smp_call_function_single’
    err = compat_smp_call_function_single(0, LinuxDriverEstimateTSCkHzWork,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/linux-4.16.3-gentoo/include/linux/percpu.h:7:0,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/percpu-rwsem.h:7,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/fs.h:33,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/highmem.h:5,
                 from /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:25:
/usr/src/linux-4.16.3-gentoo/include/linux/smp.h:32:5: note: declared here
 int smp_call_function_single(int cpuid, smp_call_func_t func, void *info,
     ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:69:0:
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c: In function ‘LinuxDriverSyncCallOnEachCPU’:
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/vmmonInt.h:34:50: error: too many arguments to function ‘smp_call_function’
 #define compat_smp_call_function(fn, info, wait) smp_call_function(fn, info, 1, wait)
                                                  ^
/var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:1224:4: note: in expansion of macro ‘compat_smp_call_function’
    compat_smp_call_function(LinuxDriverSyncCallHook, &args, 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/linux-4.16.3-gentoo/include/linux/percpu.h:7:0,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/percpu-rwsem.h:7,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/fs.h:33,
                 from /usr/src/linux-4.16.3-gentoo/include/linux/highmem.h:5,
                 from /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c:25:
/usr/src/linux-4.16.3-gentoo/include/linux/smp.h:100:5: note: declared here
 int smp_call_function(smp_call_func_t func, void *info, int wait);
     ^~~~~~~~~~~~~~~~~
distcc[32709] ERROR: compile /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.c on localhost failed
make[3]: *** [/usr/src/linux-4.16.3-gentoo/scripts/Makefile.build:325: /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work/vmmon-only/linux/driver.o] Error 1
make[3]: *** Waiting for unfinished jobs....

Revise your CFLAGS/CXXFLAGS environment variables and remove “-fomit-frame-pointer”.

In our system we used (manual compile/install):

export CFLAGS="-O2 -msse -msse2 -mssse3 -march=core2 -pipe"
export CXXFLAGS="${CFLAGS}"
export LDFLAGS="-Wl,-O1"

or for Gentoo configuration file /etc/portage/make.conf

CFLAGS="-O2 -msse -msse2 -mssse3 -march=core2 -pipe"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1"

* All needed patches in Gentoo for compiling vmware-modules 308.5.9 ( with vmware-player-12.5.9.7535481 ) successfully in a modern kernel

>>> Preparing source in /var/tmp/portage/app-emulation/vmware-modules-308.5.9/work ...
 * Applying 308-makefile-kernel-dir.patch ...                [ ok ]
 * Applying 308-makefile-include.patch ...                   [ ok ]
 * Applying 308-netdevice.patch ...                          [ ok ]
 * Applying 308-apic.patch ...                               [ ok ]
 * Applying 308-3.10-00-dentry.patch ...                     [ ok ]
 * Applying 308-3.10-01-inode.patch ...                      [ ok ]
 * Applying 308-3.10-02-control.patch ...                    [ ok ]
 * Applying 308-3.10-03-inline.patch ...                     [ ok ]
 * Applying 308-3.11-00-readdir.patch ...                    [ ok ]
 * Applying 308-3.11-01-filldir.patch ...                    [ ok ]
 * Applying 308-3.15-00-vsock.patch ...                      [ ok ]
 * Applying 308-3.18-00-version-redefined.patch ...          [ ok ]
 * Applying 308-3.19-00-compat-namei.patch ...               [ ok ]
 * Applying 308-3.19-02-vmblock-path.patch ...               [ ok ]
 * Applying 308-3.19-04-iovec.patch ...                      [ ok ]
 * Applying 308-3.19-05-vmci_qpair.patch ...                 [ ok ]
 * Applying 308-3.19-06-vsock.patch ...                      [ ok ]
 * Applying 308-3.19-07-vsock.patch ...                      [ ok ]
 * Applying 308-4.01-00-vsock.patch ...                      [ ok ]
 * Applying 308-4.02-00-nd_set_link.patch ...                [ ok ]
 * Applying 308-4.02-01-sk_alloc.patch ...                   [ ok ]
 * Applying 308-4.03-00-vmci-misc_deregister.patch ...       [ ok ]
 * Applying 308-4.05-00-vmblock-follow_link.patch ...        [ ok ]
 * Applying 308-4.06-00-user-pages.patch ...                 [ ok ]
 * Applying 308-4.07-01-readlink_copy.patch ...              [ ok ]
 * Applying 308-4.08-00-vmmon-fix-page-accounting.patch ...  [ ok ]
 * Applying 308-4.09-00-user-pages.patch ...                 [ ok ]
 * Applying 308-4.10-00-generic_readlink.patch ...           [ ok ]
 * Applying 308-4.11-00-missing-headers.patch ...            [ ok ]
 * Applying 308-4.11-01-vsock-lockdep.patch ...              [ ok ]
 * Applying 308-4.12-00-vmblock-current_time.patch ...       [ ok ]
 * Applying 308-4.12-01-vmci-do_once.patch ...               [ ok ]
 * Applying 308-4.12-02-vmci-pci_enable_msix.patch ...       [ ok ]
 * Applying 308-4.13-00-vmnet-refcount.patch ...             [ ok ]
 * Applying 308-4.13-01-vmmon-fix-page-accounting.patch ...  [ ok ]
 * Applying 308-4.14-00-vmmon-global-page-state.patch ...    [ ok ]
 * Applying 308-4.14-01-deprecated-asm-uaccess.patch ...     [ ok ]
 * Applying 308-4.15-00-init_timer.patch ...                 [ ok ]
 * Applying 308-4.16-00-vmblock-iversion.patch ...           [ ok ]
>>> Source prepared.

In fact if you come from another linux distro and need some of the patches you could always download them if you need – just paste the name of the patch file in let’s say google and you’ll get the patch or you can always add vmware overlay, but you should have Gentoo.

distccd failed to exec with “No such file or directory”

And you think your compile box using distccd is ready you start emerge in your server/desktop/laptop and the first package is OK, the your emerge is using the distccd properly and the compilation is distributed to the compile box get compiled.
But just then another package gets a warning during build time:

distcc[9356] (dcc_build_somewhere) Warning: failed to distribute, running locally instead

So everything is back in your machine not in the compile box! And you find in the logs of the distccd compile box:

Apr 23 00:36:17 compile distccd[6177]: (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-clang++: No such file or directory
Apr 23 00:36:17 compile distccd[12965]: (dcc_job_summary) client: 10.10.10.10:54946 COMPILE_ERROR exit:110 sig:0 core:0 ret:0 time:3492ms x86_64-pc-linux-gnu-clang++ ../../v8/src/accessors.cc
Apr 23 00:36:17 compile distccd[13490]: (dcc_job_summary) client: 10.10.10.10:54954 COMPILE_ERROR exit:110 sig:0 core:0 ret:0 time:1677ms x86_64-pc-linux-gnu-clang++ ../../v8/src/asmjs/asm-types.cc
Apr 23 00:36:18 compile distccd[6178]: (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-clang++: No such file or directory
Apr 23 00:36:18 compile distccd[6097]: (dcc_job_summary) client: 10.10.10.10:54956 COMPILE_ERROR exit:110 sig:0 core:0 ret:0 time:2340ms x86_64-pc-linux-gnu-clang++ ../../v8/src/assembler.cc
Apr 23 00:37:22 compile distccd[6180]: (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-clang++: No such file or directory
Apr 23 00:37:22 compile distccd[13307]: (dcc_job_summary) client: 10.10.10.10:54990 COMPILE_ERROR exit:110 sig:0 core:0 ret:0 time:1878ms x86_64-pc-linux-gnu-clang++ ../../v8/src/heap/incremental-marking-job.cc
Apr 23 00:37:23 compile distccd[6184]: (dcc_execvp) ERROR: failed to exec x86_64-pc-linux-gnu-clang++: No such file or directory
Apr 23 00:37:23 compile distccd[13719]: (dcc_job_summary) client: 10.10.10.10:54992 COMPILE_ERROR exit:110 sig:0 core:0 ret:0 time:2139ms x86_64-pc-linux-gnu-clang++ ../../v8/src/heap/incremental-marking.cc

Ahh you missed a package, then you emerge it fast with (assumed you used Gentoo, but the solution is valid for all distros)

[root@local ]# emerge -v sys-devel/clang sys-devel/clang-runtime

And start up the build process again (if Gentoo with emerge) and again the same situation? Again the same error, but you have the “x86_64-pc-linux-gnu-clang++” command and when you type x86_64-pc-linux-gnu-clang++ it executes properly! So what is the problem? The problem is that x86_64-pc-linux-gnu-clang++ is not in the current environment PATH:

compile ~ # whereis x86_64-pc-linux-gnu-clang++
x86_64-pc-linux-gnu-clang++: /usr/lib64/llvm/5/bin/x86_64-pc-linux-gnu-clang++

The solution is very simple just restart “distccd”. A trivial one, but could save you time next time! If you install a package, which is expected to be used with distccd restart distccd!!!

Under Getnoo:

compile ~ # /etc/init.d/distccd restart
 * Caching service dependencies ...
 * Stopping distccd ...  [ ok ]
 * Starting distccd ...  [ ok ]
compile ~ #

* You might get error for another file, check if it exists if not install it and then restart the distccd daemon, for example you could get error for any of these:

x86_64-pc-linux-gnu-addr2line
x86_64-pc-linux-gnu-elfedit
x86_64-pc-linux-gnu-gprof
x86_64-pc-linux-gnu-ar
x86_64-pc-linux-gnu-g++
x86_64-pc-linux-gnu-ld
x86_64-pc-linux-gnu-as
x86_64-pc-linux-gnu-g++-6.4.0
x86_64-pc-linux-gnu-ld.bfd
x86_64-pc-linux-gnu-c++
x86_64-pc-linux-gnu-g++-7.2.0
x86_64-pc-linux-gnu-ld.gold
x86_64-pc-linux-gnu-c++-6.4.0
x86_64-pc-linux-gnu-gcc
x86_64-pc-linux-gnu-libgcrypt-config
x86_64-pc-linux-gnu-c++-7.2.0
x86_64-pc-linux-gnu-gcc-6.4.0
x86_64-pc-linux-gnu-llvm-config
x86_64-pc-linux-gnu-c++filt
x86_64-pc-linux-gnu-gcc-7.2.0
x86_64-pc-linux-gnu-nm
x86_64-pc-linux-gnu-clang
x86_64-pc-linux-gnu-gcc-ar
x86_64-pc-linux-gnu-objcopy
x86_64-pc-linux-gnu-clang++
x86_64-pc-linux-gnu-gcc-nm
x86_64-pc-linux-gnu-objdump
x86_64-pc-linux-gnu-clang-5.0
x86_64-pc-linux-gnu-gcc-ranlib
x86_64-pc-linux-gnu-pcre-config
x86_64-pc-linux-gnu-clang++-5.0
x86_64-pc-linux-gnu-gcov
x86_64-pc-linux-gnu-pkg-config
x86_64-pc-linux-gnu-clang-cl
x86_64-pc-linux-gnu-gcov-6.4.0
x86_64-pc-linux-gnu-ranlib
x86_64-pc-linux-gnu-clang-cl-5.0
x86_64-pc-linux-gnu-gcov-7.2.0
x86_64-pc-linux-gnu-readelf
x86_64-pc-linux-gnu-clang-cpp
x86_64-pc-linux-gnu-gcov-dump
x86_64-pc-linux-gnu-size
x86_64-pc-linux-gnu-clang-cpp-5.0
x86_64-pc-linux-gnu-gcov-tool
x86_64-pc-linux-gnu-strings
x86_64-pc-linux-gnu-cpp
x86_64-pc-linux-gnu-gfortran
x86_64-pc-linux-gnu-strip
x86_64-pc-linux-gnu-cpp-6.4.0
x86_64-pc-linux-gnu-gfortran-6.4.0
x86_64-pc-linux-gnu-xml2-config
x86_64-pc-linux-gnu-cpp-7.2.0
x86_64-pc-linux-gnu-gfortran-7.2.0
x86_64-pc-linux-gnu-xslt-config
x86_64-pc-linux-gnu-curl-config
x86_64-pc-linux-gnu-gio-querymodules

Resume compilation of a packet from where it failed under Gentoo

Sometimes problems are too specific, but they can show us a path to look for a more general problem and its solution. There was a nasty bug in emerging Firefox package in Gentoo basically it compiled all the source and then it got an error from the build script, but all the source was compiled successfully! So the solution was just to manually install with

ebuild

the package and not to wait for the fix 😉 A good workaround.

But what if we have a big package, which failed during compilation

because of “out of ram” or “out of space” or a missing library, which the maintainer did not included in the dependencies. So tens of minutes or even hours of compilation (yes, there are still such packets like chromium) is wasted and we must start up from the beginning? No you can continue the current failed compilation from the exact point of failure using “ebuild”.
In our example we have a failed compilation of chromium with “out of memory”. We need the exact version of the package, scroll to your emerge command and copy the version, in our case it was: chromium-67.0.3377.1.ebuild
Here are the commands:

STEP 1) Continue compilation

[root@local ]# ebuild /usr/portage/www-client/chromium/chromium-67.0.3377.1.ebuild compile
>>> Existing ${T}/environment for 'chromium-67.0.3377.1' will be sourced.
>>> Run 'clean' to start with a fresh environment.
>>> Checking chromium-67.0.3377.1.tar.xz's mtime...
>>> WORKDIR is up-to-date, keeping...
 * checking ebuild checksums 😉 ...                                                                                                    [ ok ]
 * checking auxfile checksums 😉 ...                                                                                                   [ ok ]
 * checking miscfile checksums 😉 ...                                                                                                  [ ok ]
 * Checking for at least 3 GiB RAM ...                                                                                                  [ ok ]
 * Checking for at least 5 GiB disk space at "/var/tmp/portage/www-client/chromium-67.0.3377.1/temp" ...                                [ ok ]
>>> It appears that 'setup' has already executed for 'chromium-67.0.3377.1'; skipping.
>>> Remove '/var/tmp/portage/www-client/chromium-67.0.3377.1/.setuped' to force setup.
>>> It appears that 'unpack' has already executed for 'chromium-67.0.3377.1'; skipping.
>>> Remove '/var/tmp/portage/www-client/chromium-67.0.3377.1/.unpacked' to force unpack.
>>> It appears that 'prepare' has already executed for 'chromium-67.0.3377.1'; skipping.
>>> Remove '/var/tmp/portage/www-client/chromium-67.0.3377.1/.prepared' to force prepare.
>>> It appears that 'configure' has already executed for 'chromium-67.0.3377.1'; skipping.
>>> Remove '/var/tmp/portage/www-client/chromium-67.0.3377.1/.configured' to force configure.
>>> Compiling source in /var/tmp/portage/www-client/chromium-67.0.3377.1/work/chromium-67.0.3377.1 ...
ninja -v -j6 -l6 -C out/Release mksnapshot
ninja: Entering directory `out/Release'

As you can see in the output above an existing environment for ‘chromium-67.0.3377.1’ will be sourced.
Here the compilation continue from the last failed compilation script, it skipped multiple source dependencies.

STEP 2) Install the package

In fact two commands:

ebuild /usr/portage/www-client/chromium/chromium-67.0.3377.1.ebuild install
ebuild /usr/portage/www-client/chromium/chromium-67.0.3377.1.ebuild qmerge

The first command “install” will install the package in the working directory of the emerge process and then the second “qmerge” will install all the files of the package in the install directory to the live filesystem and will do some additional checks and modifications in your systems package database to install the package properly as if the emerge was used.