genkernel – ERROR: Unable to generate splash, ‘splash_geninitramfs’ was not found!

If you tried recently to build your kernel with genkernel (4.0.0_beta17, but you will have the same problem with 3.x) you may end up with the following error:

* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!

The splash_geninitramfs was part of the removed Gentoo ebuild package – “media-gfx/splashutils“. The software in the package splashutils had not been maintained for a really long time and eventually, it was removed. At present, there is no package offering the splash_geninitramfs. Still, the same functionality could be archived with “sys-boot/plymouth“, but the genkernel does not have the option to use it.
The genkernel command option, which triggers the error is “–splash” you must remove it. And check whether the following option in “/etc/genkernel.conf” is set to “no” (at least, in genkernel version 3.x is the default set to “yes”):

SPLASH="no"

When you instruct the genkernel not to add boot splash using splashutils the error will be gone and the kernel build will be successful.

The output error

We include the output error when using “–splash” with genkernel and the last part of genkernel.log.

livecd ~ # genkernel --splash --install --clean --no-mrproper --menuconfig all
* Gentoo Linux Genkernel; Version 4.0.0_beta17
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --splash --install --clean --no-mrproper --menuconfig all

* Working with Linux kernel 5.3.1-gentoo for x86_64
* Using kernel config file '/usr/share/genkernel/arch/x86_64/generated-config' ...
* 
* Note: The version above is subject to change (depends on config and status of kernel sources).

* kernel: >> Initializing ...
*         >> Running 'make clean' ...
*         >> --no-mrproper is set; Skipping 'make mrproper' ...
*         >> Running 'make oldconfig' ...
*         >> Invoking menuconfig ...
*         >> Re-running 'make oldconfig' due to changed kernel options ...
*         >> Kernel version has changed (probably due to config change) since genkernel start:
*            We are now building Linux kernel 5.3.1-gentoo-x86_64 for x86_64 ...
*         >> Compiling 5.3.1-gentoo-x86_64 bzImage ...
*         >> Compiling 5.3.1-gentoo-x86_64 modules ...
*         >> Installing 5.3.1-gentoo-x86_64 modules (and stripping) ...
*         >> Generating module dependency data ...
*         >> Saving config of successful build to '/etc/kernels/kernel-config-5.3.1-gentoo-x86_64' ...

* initramfs: >> Initializing ...
*         >> Appending devices cpio data ...
*         >> Appending base_layout cpio data ...
*         >> Appending auxilary cpio data ...
*         >> Appending blkid cpio data ...
*         >> Appending busybox cpio data ...
*         >> Appending mdadm cpio data ...
*         >> Appending modprobed cpio data ...
*         >> Appending splash cpio data ...
* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!
* Please consult '/var/log/genkernel.log' for more information and any
* errors that were reported above.
* 
* Report any genkernel bugs to bugs.gentoo.org and
* assign your bug to genkernel@gentoo.org. Please include
* as much information as you can in your bug report; attaching
* '/var/log/genkernel.log' so that your issue can be dealt with effectively.
* 
* Please do *not* report kernel compilation failures as genkernel bugs!

livecd ~ # cat /var/log/genkernel.log
.....
.....
*         >> Appending splash cpio data ...

* ERROR: Unable to generate splash, 'splash_geninitramfs' was not found!
* Please consult '/var/log/genkernel.log' for more information and any
* errors that were reported above.
* 
* Report any genkernel bugs to bugs.gentoo.org and
* assign your bug to genkernel@gentoo.org. Please include
* as much information as you can in your bug report; attaching
* '/var/log/genkernel.log' so that your issue can be dealt with effectively.
* 
* Please do *not* report kernel compilation failures as genkernel bugs!
* 

* mount: >> '/boot' is not a mountpoint; Nothing to restore ...
>>> Ended on: 2019-09-30 18:11:20 (after 0 days 0 hours 08 minutes 06 seconds)

CentOS 7 – Your kernel headers for kernel cannot be found at – missing kernel-devel

Getting the following error may be deceiving:

Error! echo
Your kernel headers for kernel 3.10.0-1062.1.1.el7.x86_64 cannot be found at
/lib/modules/3.10.0-1062.1.1.el7.x86_64/build or /lib/modules/3.10.0-1062.1.1.el7.x86_64/source.

Because you may have already installed the kernel-headers package for the current kernel and still to get the same error. So what is missing?

In fact, the kernel headers for compiling a kernel module is in kernel-devel package.

[root@localhost ~]# yum install kernel-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.wwfx.net
 * extras: mirror.wwfx.net
 * updates: mirror.wwfx.net
Resolving Dependencies
--> Running transaction check
---> Package kernel-devel.x86_64 0:3.10.0-1062.1.1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================
 Package                                   Arch                                Version                                           Repository                            Size
============================================================================================================================================================================
Installing:
 kernel-devel                              x86_64                              3.10.0-1062.1.1.el7                               updates                               18 M

Transaction Summary
============================================================================================================================================================================
Install  1 Package

Total download size: 18 M
Installed size: 38 M
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
kernel-devel-3.10.0-1062.1.1.el7.x86_64.rpm                                                                                                          |  18 MB  00:00:02     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-devel-3.10.0-1062.1.1.el7.x86_64                                                                                                                  1/1 
  Verifying  : kernel-devel-3.10.0-1062.1.1.el7.x86_64                                                                                                                  1/1 

Installed:
  kernel-devel.x86_64 0:3.10.0-1062.1.1.el7                                                                                                                                 

Complete!

If you have used other Linux distribution the “kernel headers”/”linux headers” package just means what it is named. In the CentOS 7 world there are two packages:

[root@localhost ~]# yum info kernel-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.wwfx.net
 * extras: mirror.wwfx.net
 * updates: mirror.wwfx.net
Installed Packages
Name        : kernel-devel
Arch        : x86_64
Version     : 3.10.0
Release     : 1062.1.1.el7
Size        : 38 M
Repo        : installed
From repo   : updates
Summary     : Development package for building kernel modules to match the kernel
URL         : http://www.kernel.org/
License     : GPLv2
Description : This package provides kernel headers and makefiles sufficient to build modules
            : against the kernel package.

[root@localhost ~]# yum info kernel-headers
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.wwfx.net
 * epel: mirrors.neterra.net
 * extras: mirror.wwfx.net
 * updates: mirror.wwfx.net
Installed Packages
Name        : kernel-headers
Arch        : x86_64
Version     : 3.10.0
Release     : 1062.1.1.el7
Size        : 3.7 M
Repo        : installed
From repo   : updates
Summary     : Header files for the Linux kernel for use by glibc
URL         : http://www.kernel.org/
License     : GPLv2
Description : Kernel-headers includes the C header files that specify the interface
            : between the Linux kernel and userspace libraries and programs.  The
            : header files define structures and constants that are needed for
            : building most standard programs and are also needed for rebuilding the
            : glibc package.

Install Nginx virtual host traffic status module – traffic information in nginx and more per server block and upstreams

This article is going to show how to compile and install the Nginx module – ngx_http_vhost_traffic_status.

The module gathers traffic information per the server blocks and upstream servers and shows information for Nginx proxy cache like used space.

In addition, the module shows the type of the Response – 1xx, 2xx, 3xx, 4xx, 5xx and total. So when if problems occur in a server block or an upstream server
This module nginx-module-vts offers really extended status information for your Nginx.
Here is one the status page of our web servers with 18 virtual hosts:

The status page shows all virtual hosts in section “Server zones” and all upstream servers for the FastCGI PHP backend servers.

Traffic, requests, and status codes are available. All data is available in JSON, too.

main menu
Traffic information in Nginx and more per server block and upstreams

Server zones information

  • Requests – Total, Requests/s, Time
  • Responses – 1xx, 2xx, 3xx, 4xx, 5xx, Total
  • Traffic – Sent, Received, Sent/s, Received/s
  • Cache – Miss, Bypass, Expired, Stale, Updating, Revalidated, Hit, Scarce, Total

In addition to the information above there are State, Response Time, Weight, MaxFails and FileTimeout for all the upstream servers. And for the Nginx proxy cache there are Size, Capacity (live information!) and all information above per zone – there is an additional article here Live status information like used space and more for nginx proxy cache.
Keep on reading!

PHP 7.2 or PHP 7.3 with mcrypt – manual build

Newer PHP versions do not include PHP mcrypt library. The mcrypt module was part of PHP 5 till 7.1, in which it was deprecated and removed in 7.2. If you open the php.net documentation for mcrypt PHP functions you will see:

This function has been DEPRECATED as of PHP 7.1.0 and REMOVED as of PHP 7.2.0. Relying on this function is highly discouraged.

The mcrypt module is now in PHP PECL (repository for PHP Extensions) in https://pecl.php.net/package/mcrypt. As you can see in the description, this is a legacy module, which

Provides bindings for the unmaintained libmcrypt.

, so it is strongly recommended to replace it with OpenSSL (for example).
Still, if you need this legacy module – mcrypt and :

You may want to manually build the mcrypt module for your current installed PHP. Of course, the generic dependencies are:

  1. libmcrypt and its headers (if the Linux distribution) splits the binary and the headers
  2. GNU GCC
  3. PHP 7.2+
  4. download the latest mcrypt module source from https://pecl.php.net/package/mcrypt. For example, now it is https://pecl.php.net/get/mcrypt-1.0.2.tgz
mkdir /root/mcrypt-php-module-manual
cd /root/mcrypt-php-module-manual
wget https://pecl.php.net/get/mcrypt-1.0.2.tgz
tar xzf mcrypt-1.0.2.tgz
cd mcrypt-1.0.2
phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make
make install

Do not use “make -j N” (“make -j 8”, for example), because it may fail to compile.
Keep on reading!

Gentoo building qtgui error – g++-v8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory

Most cases this error happens after you updated the GNU GCC (this update triggers the error, but it might be not the problem)! This was the case with us we updated the GNU GCC and then wanted to update QT libraries and several packages were built OK, but then this error occurred when compiling dev-qt/qtgui.

x86_64-pc-linux-gnu-g++ -c -march=haswell -O2 -fomit-frame-pointer -pipe -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWHELPERS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_CORE_LIB -I. -I../../include -I../../include/QtGui -I../../include/QtGui/5.11.2 -I../../include/QtGui/5.11.2/QtGui -I.tracegen -isystem /usr/include/libdrm -isystem /usr/include -isystem /usr/include/qt5/QtCore/5.11.2 -isystem /usr/include/qt5/QtCore/5.11.2/QtCore -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -I.moc -isystem /usr/include/libpng16 -I../../mkspecs/linux-g++ -o .obj/qaccessible.o accessible/qaccessible.cpp
distcc[8024] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/stl_algo.h:59,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/algorithm:62,
                 from ../../include/QtCore/../../src/corelib/global/qglobal.h:142,
                 from ../../include/QtCore/qglobal.h:1,
                 from ../../include/QtGui/../../src/gui/kernel/qtguiglobal.h:43,
                 from ../../include/QtGui/qtguiglobal.h:1,
                 from ../../include/QtGui/../../src/gui/image/qimage.h:43,
                 from ../../include/QtGui/qimage.h:1,
                 from image/qimage_sse4.cpp:40:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
distcc[8012] ERROR: compile image/qimage_sse4.cpp on localhost failed
make: *** [Makefile:2414: .obj/qimage_sse4.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/stl_algo.h:59,
                 from /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/algorithm:62,
                 from ../../include/QtCore/../../src/corelib/global/qglobal.h:142,
                 from ../../include/QtCore/qglobal.h:1,
                 from ../../include/QtGui/../../src/gui/kernel/qtguiglobal.h:43,
                 from ../../include/QtGui/qtguiglobal.h:1,
                 from ../../include/QtGui/5.11.2/QtGui/private/../../../../../src/gui/kernel/qtguiglobal_p.h:54,
                 from ../../include/QtGui/5.11.2/QtGui/private/qtguiglobal_p.h:1,
                 from ../../include/QtGui/5.11.2/QtGui/private/../../../../../src/gui/painting/qdrawhelper_p.h:54,
                 from ../../include/QtGui/5.11.2/QtGui/private/qdrawhelper_p.h:1,
                 from painting/qdrawhelper_sse4.cpp:40:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.

Keep on reading!

portage is blocked by “the current version of portage supports EAPI ‘6’. You must upgrade”

We’ve synced the portage tree before upgrading our old portage package (big mistake! always upgrade the portage package before sync) and then do the sync. After the sync the portage upgrade was impossible, because a dependency package supported only a new portage API (probably a new package) in our case EAPI 7 and the offensive package was “app-eselect/eselect-pinentry“.
So there are two options:

  1. Find the last version of the portage,which does not depend on the package – app-eselect/eselect-pinentry
  2. Find if some of the USE flags disable the inclusion of this dependency – app-eselect/eselect-pinentry

We chose the second option and found that if we compiled the portage package with

-rsync-verify

the portage did not pull the dependency “app-eselect/eselect-pinentry” and then after a successful upgrade we had the portage supported EAPI 7 and reinstalled it with activated “-rsync-verify”.
Keep on reading!

pycurl.h: fatal error: openssl/ssl.h: No such file or directory

If you encounter this error trying to install a pip module or compile a program under the console you surely miss OpenSSL development packages!
pip also may build a packages in your system and it could depend on generic library headers like in this case OpenSSL, which the installer (pip) won’t bring them and it will output an error as you can see

myuser@srv # sudo pip install pycurl pygeoip psutil
Collecting pycurl
  Using cached https://files.pythonhosted.org/packages/e8/e4/0dbb8735407189f00b33d84122b9be52c790c7c3b25286826f4e1bdb7bde/pycurl-7.43.0.2.tar.gz
Requirement already satisfied (use --upgrade to upgrade): pygeoip in /usr/local/lib/python2.7/dist-packages
Requirement already satisfied (use --upgrade to upgrade): psutil in /usr/lib/python2.7/dist-packages
Building wheels for collected packages: pycurl
  Running setup.py bdist_wheel for pycurl ... error
  Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-AbCshS/pycurl/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmpqVNq1upip-wheel- --python-tag cp27:
  Using curl-config (libcurl 7.47.0)
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-2.7
  creating build/lib.linux-x86_64-2.7/curl
  copying python/curl/__init__.py -> build/lib.linux-x86_64-2.7/curl
  running build_ext
  building 'pycurl' extension
  creating build/temp.linux-x86_64-2.7
  creating build/temp.linux-x86_64-2.7/src
  x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPYCURL_VERSION="7.43.0.2" -DHAVE_CURL_SSL=1 -DHAVE_CURL_OPENSSL=1 -DHAVE_CURL_SSL=1 -I/usr/include/python2.7 -c src/docstrings.c -o build/temp.linux-x86_64-2.7/src/docstrings.o
  In file included from src/docstrings.c:4:0:
  src/pycurl.h:164:28: fatal error: openssl/ssl.h: No such file or directory
  compilation terminated.
  error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
  
  ----------------------------------------
  Failed building wheel for pycurl
  Running setup.py clean for pycurl
Failed to build pycurl
Installing collected packages: pycurl
  Running setup.py install for pycurl ... error
    Complete output from command /usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-AbCshS/pycurl/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-oea_jq-record/install-record.txt --single-version-externally-managed --compile:
    Using curl-config (libcurl 7.47.0)
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/curl
    copying python/curl/__init__.py -> build/lib.linux-x86_64-2.7/curl
    running build_ext
    building 'pycurl' extension
    creating build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/src
    x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -DPYCURL_VERSION="7.43.0.2" -DHAVE_CURL_SSL=1 -DHAVE_CURL_OPENSSL=1 -DHAVE_CURL_SSL=1 -I/usr/include/python2.7 -c src/docstrings.c -o build/temp.linux-x86_64-2.7/src/docstrings.o
    In file included from src/docstrings.c:4:0:
    src/pycurl.h:164:28: fatal error: openssl/ssl.h: No such file or directory
    compilation terminated.
    error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
    
    ----------------------------------------
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-AbCshS/pycurl/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-oea_jq-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-AbCshS/pycurl/
You are using pip version 8.1.1, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command

Keep on reading!

Compilation failure in configure with syntax error near unexpected token -Wall,WFLAGS and AX_CHECK_COMPILE_FLAG

If you are trying to build program and in the configure stage you got something like this:

./configure: line 6849: syntax error near unexpected token `-Wall,WFLAGS="$WFLAGS -Wall"'
./configure: line 6849: `AX_CHECK_COMPILE_FLAG(-Wall,WFLAGS="$WFLAGS -Wall")'

You are missing

autoconf-archive

Check your system for the package including this software (a collection of freely re-usable Autoconf macros): https://www.gnu.org/software/autoconf-archive/

In our case we were experiencing a missing dependency for “app-admin/metalog” in Gentoo Linux system. Probably there is a bug, because autoconf-archive is not in the dependency graph of “app-admin/metalog” (app-admin/metalog-20181125), but it should be included.
Such kind of error could occur in all Linux systems. Here is what to install in

  • CentOS 7
    yum install autoconf-archive
    
  • Ubuntu 16/17/18+
  • apt install autoconf-archive
    
  • Gentoo Linux
  • emerge -va autoconf-archive
    

Gentoo distcc compilation error – relocation R_X86_64_32 against .rodata.str1.1 can not be used when making a shared object

In our Gentoo systems we use distcc (distributed builds for C, C++ and Objective C) to build the packages fast! But after we upgraded to GNU GCC 8.2 some of the packages we tried to build failed with:

 0:02.86 /usr/lib64/distcc/bin/x86_64-pc-linux-gnu-gcc -std=gnu99 -o nsinstall_real -DXP_UNIX -O2  host_nsinstall.o host_pathsub.o
 0:02.88 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: host_nsinstall.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
 0:02.88 host_nsinstall.o: error adding symbols: Bad value
 0:02.88 collect2: error: ld returned 1 exit status
 0:02.88 distcc[528] ERROR: compile (null) on localhost failed

As you know the GNU GCC must be (same versions and) compiled with the same flags on the two systems you use it – the local machine and the distcc build server. So we were pretty sure the GNU GCC is the same version in our local machine and the build distcc server, because the USE flags were the same in /etc/portage/make.conf but executing

gcc -v

showed there is a slight difference.
The local machine

srv.local ~ # gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.2.0-r3 p1.4' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)

The distcc server:

compile ~ # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-8.2.0-r3/work/gcc-8.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.2.0-r3 p1.4' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)

The difference is in local has –enable-default-pie and distcc server has –disable-default-pie

Investigating farther we discovered that the USE make.conf flag is “pie” – https://packages.gentoo.org/useflags/pie and this flag is for “Build programs as Position Independent Executables (a security hardening technique)”. And the problem was the default value on the local machine it was enabled by default and for the remote it was disabled by default –

SO the real problem was the different profiles set on the two servers!

The remote distcc server no one checked and switched to the new portage profile 17 so the server still used the old portage profile 13, where the flag “pie” was excluded.
So change the profile to the same as the local machine and recompile GNU GCC package:

compile ~ # eselect profile set 12
compile ~ # emerge -va gcc

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

Calculating dependencies... done!
[ebuild   R    ] sys-devel/gcc-8.2.0-r3:8.2.0::gentoo  USE="cxx fortran (multilib) nls nptl openmp pch (pie*) sanitize ssp vtv (-altivec) -debug -doc (-fixed-point) -go -graphite (-hardened) (-jit) (-libssp) -mpx -objc -objc++ -objc-gc -pgo -regression-test -systemtap -vanilla" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] Yes

As you can see the new flag enabled by “(pie*)”.

So be sure when using distcc the Gentoo portage profiles should be the same on the local and the remote distcc systems or you can end up with fatal differences and compilation errors!

Rebuild the official Ubuntu kernel – Ubuntu 16.04 LTS

There are multiple reasons to rebuild the official kernel of a Linux distro but this is not the purpose of this article

just cannot miss the chance to write that all the kernels are built therefore optimized for the very first 64bit Intel/AMD processor! But come on who wants the most important piece of software to be optimized not for his new and expensive processor but for one released 15 years ago???

. Here we are going to show you how to recompile the latest official Ubuntu kernel of Ubuntu 16.04 LTS – the one, which comes with the apt packages system, because this kernel comes with the latest and greatest patches of the Ubuntu team. You should not confuse this howto with the one, which compile a vanilla kernel or the mainline kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/. So if you want a new kernel or the latest from kernel.org this is the right tutorial for Ubuntu – Build your own kernel under Ubuntu using mainline (latest) kernel. The official latest kernel in the Ubuntu repository is not always the latest one from kernel.org, but you can be sure it is probably most secure one, because there are additional modifications, configurations and tests by the team. Here you can see what versions of the kernel are the officials in Ubuntu: https://wiki.ubuntu.com/Kernel/Support

Keep on reading!