Tag: gentoo

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 Perl update tips here: Gentoo update tips when updating packages with blocks and masked files
And a new article on the subject – Gentoo – updating perl and problems like perl-core/ is blocking virtual/perl-
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 package, 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 package 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 packages 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.

Compilation failure with Value too large for defined data type in Gentoo

It has happened several times for the last 10 years, a program to fail during the configure stage with a strange error:

checking whether we are cross compiling...  * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type):
 * ISE: fopen_wr(conftest.out)
        abs_path: (null)
        res_path: /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86/conftest.out
configure: error: in `/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

It’s like the “./conftest” is made and the execution failed?

Last package it happened was when trying to build

sys-apps/sandbox-2.13

but it is not especially related to this Gentoo package or even to Gentoo!

And the debug.log is not informative neither:

configure:3793: ./conftest
/usr/lib32/libsandbox.so(+0xb238)[0xf7738238]
/usr/lib32/libsandbox.so(+0xb2c7)[0xf77382c7]
/usr/lib32/libsandbox.so(+0x40b1)[0xf77310b1]
/usr/lib32/libsandbox.so(+0x421e)[0xf773121e]
/usr/lib32/libsandbox.so(fopen+0x55)[0xf7733e45]
./conftest(+0x4a1)[0x565754a1]
/lib32/libc.so.6(__libc_start_main+0xf6)[0xf7561956]
./conftest(+0x508)[0x56575508]
/proc/23882/cmdline: ./conftest 

/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/configure: line 3795: 23882 Aborted                 ./conftest$ac_cv_exeext
configure:3797: $? = 134
configure:3804: error: in `/var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13-abi_x86_32.x86':
configure:3806: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

After some debugging it turned out the problem was the

XFS filesystem

The root was formatted with XFS and therefore

/var/tmp/portage

where all the compilation occurred was on a xfs formatted partition!
It is easy to resolve the issue, just mount your “/var/tmp/portage” on another filesystem, if you do not have any spare devices or places with other filesystem, you could always mount it using

tmpfs

(using your memory for the directory) like this:

mount -t tmpfs -o size=4096m tmpfs /var/tmp/portage/

You can adjust the size with “size” parameter, but most of the program require a way below 4G of space. And do not forget mounting your build directory in the tmpfs speeds up the emerge process significantly!

And probably it is a good idea before mounting it to delete all old sub-directories, because they can take much space and they are left there after failed compilations of packages.

rm -R /var/tmp/portage/*

PS: It was the same with compilation of

sys-devel/gcc-7.3.0

configure: updating cache ./config.cache
 * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/libsandbox.c:check_syscall():968: failure (Value too large for defined data type):
 * ISE: fopen_wr(conftest.val)
        abs_path: (null)
        res_path: /var/tmp/portage/sys-devel/gcc-7.3.0/work/build/x86_64-pc-linux-gnu/32/libgomp/conftest.val
configure: error: unsupported system, cannot find sizeof (omp_lock_t)
make[2]: *** [Makefile:20106: configure-stage1-target-libgomp] Error 1
make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
make[1]: *** [Makefile:22189: stage1-bubble] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
make: *** [Makefile:22521: bootstrap-lean] Error 2
 * ERROR: sys-devel/gcc-7.3.0::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=sys-devel/gcc-7.3.0::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-devel/gcc-7.3.0::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-devel/gcc-7.3.0/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-devel/gcc-7.3.0/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-devel/gcc-7.3.0/work/build'
 * S: '/var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-7.3.0'
 * 
 * Please include /var/tmp/portage/sys-devel/gcc-7.3.0/work/gcc-build-logs.tar.bz2 in your bug report.
 * 

>>> Failed to emerge sys-devel/gcc-7.3.0, Log file:

The problem is the same, compiling on

XFS filesystem

Gentoo emerge a package with a custom option passed to the configure

Gentoo is a source-based Linux distro and each time we want to install a package in fact we compile it with the system program emerge. In most cases, we have USE flags for everything we need about a package, but we can further pass custom options directly to the configure script of the package through the emerge program. Using this method we can tune more subtle the configuration stage of a package and still using the package manager of the system, which is always the preferred way!
For example, we can install manually additional libraries in /usr/local/ or any other directory and we can use them passing the needed configuration to the configure script of the package. Let’s say we want to use a new feature of the latest OpenSSL library, but we do not want to install it globally and re-emerge everything linked to it, so we build it manually in a directory like /usr/local/openssl-1.1.1/ and we want to link our PHP against it, but the PHP is better to be installed by the emerge (the package manager) because it has many features like init script, the global default path to configurations and so on. So we can execute the following command:

EXTRA_ECONF="--with-openssl-dir=/usr/local/openssl-1.1.1/" emerge -avt php

you can use EXTRA_ECONF=”” to include options, which do not have USE flags. However there is a limitation, EXTRA_ECONF works only for autotools based ./configure scripts when the ebuild is using econf, so package not using autotools ./configure scripts won’t include the extra options.
It is good practice to make persistent this configuration over builds, so we can use

/etc/portage/package.env

to save the configuration for future building of the package:

echo "EXTRA_ECONF=\"--with-openssl-dir=/usr/local/openssl-1.1.1/\"" > /etc/portage/env/php.conf
echo "dev-lang/php php.conf" > /etc/portage/package.env

Create a simple spamassassin rule to catch words

Not so often we need to write our custom rules for fighting against spam, but sometimes we need it, because a spammer just wanted to target specifically our server or clients. If you use spamassassin here what you can do to create a simple rule to find words and rate the message with a desired score, which will (probably) mark it as a spam.
The template is as follows:

  • headers search, the example template is for the Subject header, but you could any other header name. 
    header <RULENAME> Subject =~ /word1, word2, word3, ..., wordN/
score <RULENAME> <score>
describe <RULENAME> <description>
  • body search 
    body <RULENAME> /word1, word2, word3, ..., wordN/
score <RULENAME> <score>
describe <RULENAME> <description>

Set these 3 lines (or the 6 above for the headers and body) in your user_prefs.cf file, which is probably here:

  • /etc/mail/spamassassin/local.cf – CentOS 7
  • /etc/spamassassin/ – Ubuntu 16/17, Gentoo
  • ~/.spamassassin/user_prefs.cf – custom file per user

Here is example of the rules:

header CONTAINS_VIG Subject =~ /apple, orange/
score CONTAINS_VIG 1.5
describe CONTAINS_VIG Bad Word fruits in the Subject
body CONTAINS_PEN /apple, orange/
score CONTAINS_PEN 1.5
describe CONTAINS_PEN Bad Word in the Body

Catch messages in the Subject and body containing apple and orange and add to the scoring system 1.5, for your purses you may need to increase the scoring drastically it depends on your required score for spam (check for it in local.cf).

* Update

As of Rob Morin proposed in the comments it is a good idea to add “/i” to catch lower and capital letters (“ignore case”) like this:

header CONTAINS_VIG Subject =~ /apple, orange/i
score CONTAINS_VIG 1.5
describe CONTAINS_VIG Bad Word fruits in the Subject
body CONTAINS_PEN /apple, orange/i
score CONTAINS_PEN 1.5
describe CONTAINS_PEN Bad Word in the Body

Access Violation error, when compiling packages in Gentoo

Sometimes if you try to emerge a package in Gentoo you could receive error in the configure phase of the compilation process. The example below is with the emerging the PHP – dev-lang/php-5.6.33:5.6::gentoo, but could happen with many other packages, which are rather old and probably not maintained or the sandbox or even the portage packages are old.
So here is the error and the compilation stops:

srv ~ # emerge -av --nodeps "<php-7"
...
checking for mmap() using MAP_ANON shared memory support... yes
checking for mmap() using /dev/zero shared memory support... yes
checking for mmap() using shm_open() shared memory support...  * ACCESS DENIED:  open_wr:      /run/test.shm.8811LBKone
no
checking for mmap() using regular file shared memory support... yes
...
checking for mmap() using MAP_ANON shared memory support... yes
checking for mmap() using /dev/zero shared memory support... yes
checking for mmap() using shm_open() shared memory support...  * ACCESS DENIED:  open_wr:      /run/test.shm.180309hAMbj
no
checking for mmap() using regular file shared memory support... yes
....
Thank you for using PHP.
config.status: creating php5.spec
config.status: creating main/build-defs.h
config.status: creating scripts/phpize
config.status: creating scripts/man1/phpize.1
config.status: creating scripts/php-config
config.status: creating scripts/man1/php-config.1
config.status: creating ext/phar/phar.1
config.status: creating ext/phar/phar.phar.1
config.status: creating main/php_config.h
config.status: executing libtool commands
config.status: executing default commands
>>> Source configured.
 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/log/sandbox/sandbox-13466.log"
 * 
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: open_wr
S: deny
P: /run/test.shm.21532Xx6ViE
A: /run/test.shm.21532Xx6ViE
R: /run/test.shm.21532Xx6ViE
C: ./conftest 

F: open_wr
S: deny
P: /run/test.shm.31817hurGxH
A: /run/test.shm.31817hurGxH
R: /run/test.shm.31817hurGxH
C: ./conftest 

F: open_wr
S: deny
P: /run/test.shm.8811LBKone
A: /run/test.shm.8811LBKone
R: /run/test.shm.8811LBKone
C: ./conftest 

F: open_wr
S: deny
P: /run/test.shm.180309hAMbj
A: /run/test.shm.180309hAMbj
R: /run/test.shm.180309hAMbj
C: ./conftest 
 * --------------------------------------------------------------------------------

>>> Failed to emerge dev-lang/php-5.6.33, Log file:

>>>  '/var/tmp/portage/dev-lang/php-5.6.33/temp/build.log'

You could try adding “-sandbox” to feature in “/etc/portage/make.conf”

FEATURES="-sandbox"

But

the sandbox feature is very important and should not be disabled by default.

And that’s why sometime when you disable it with “-sandbox” you still get access violation and you still cannot install/compile the package!
The thing is you see the error and you can fix it easily. The important part is the directory, which causes the error, in the above example with “dev-lang/php”, but could be any other Gentoo package, the problem is the writing permission for files in “/run” directory. So open the configuration file

/etc/sandbox.d/00default

and you’ll see the there is a variable called SANDBOX_WRITE, which accept paths. If you add to this variable at the end the directory “/run” or your access violated directory you’ll be able to install/compile your package with no problems, for the above problem the solution was:

SANDBOX_WRITE="/usr/tmp/conftest:/usr/lib/conftest:/usr/lib32/conftest:/usr/lib64/conftest:/usr/tmp/cf:/usr/lib/cf:/usr/lib32/cf:/usr/lib64/cf:/run"

glibc 2.26 and failure to compile because of xlocale.h

Since release of glibc 2.26 there is no xlocale.h file any more, because there was never intended to be as separate file! According to the Release notes of glibc 2.26 this file

was a strict subset of the standard header locale.h

Apparently this file had had to be used only internally for the glibc, but many programs used it directly and now they fail to compile with:

In file included from /usr/include/mlt/framework/mlt_animation.h:27:0,
                    from /usr/include/mlt/framework/mlt.h:39,
                    from /usr/include/mlt++/MltAnimation.h:26,
                    from /usr/include/mlt++/Mlt.h:24,
                    from /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.h:2 ,
                    from /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.cpp:21:
    /usr/include/mlt/framework/mlt_property.h:34:10: fatal error: xlocale.h: No such file or directory
    #include <xlocale.h>
            ^~~~~~~~~~~
    compilation terminated.
    distcc[19778] ERROR: compile /var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1/thumbnailer/mltpreview.cpp on localhost failed
    make[2]: *** [thumbnailer/CMakeFiles/mltpreview.dir/build.make:63: thumbnailer/CMakeFiles/mltpreview.dir/mltpreview.cpp.o] Error 1
    make[2]: Leaving directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'
    make[1]: *** [CMakeFiles/Makefile2:1434: thumbnailer/CMakeFiles/mltpreview.dir/all] Error 2
    make[1]: *** Waiting for unfinished jobs....
    make[2]: Leaving directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'
    make -f renderer/CMakeFiles/kdenlive_render.dir/build.make renderer/CMakeFiles/kdenlive_render.dir/build
    make[2]: Entering directory '/var/tmp/portage/kde-apps/kdenlive-17.12.1/work/kdenlive-17.12.1_build'

The above output is from a Gentoo linux distro trying to compile the kde-apps/kdenlive (kde-apps/kdenlive-17.12.1), but it is a known fact that many programs used the file and you may see another program to fail with the same or similar compilation error. You may encounter such errors when compiling perl or perl modules.
The workaround till the maintainer (if the project is alive, of course) fixes it is so simple, just link the missing file with a symbolic link:

ln -s /usr/include/locale.h /usr/include/xlocale.h