emerge – cannot sync with gpg: keyserver refresh failed: General error because of wrong date

Trying to sync one of our virtual servers we got a sync error not able to refresh the OpenPGP keys. The virtual server was just resumed and it was OK before the pause. In addition, there were no errors in dmesg or some kind of kernel panics. All seemed to be working even the server was in the distributed compiling node and no problems there. But still, the emerge syncing the portage tree wasn’t possible!
And the problem was the date of our virtual server, which was 4 months behind the real date!

Check the time and date of the server – if it is behind or in the future with a big interval this is the root of the problems with the inability to refresh the GPG keys.

Just synchronize the clock of the server and be careful when you resume pause virtual servers! When you resume them you should synchronize the clock because in multiple environments the clock might be wrong!
We have multiple articles on the time syncronization topic – openntpd – immediately sync the clock on startup, simple time synchronization of a server (laptop, desktop) using built-in systemd-timesyncd service and more.

compile-local ~ # emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: General error

^C

Exiting on signal Signals.SIGINT
compile-local ~ # date
Sat 08 Apr 2019 15:11:39 PM -00
compile-local ~ # /etc/init.d/ntpd restart
 * Starting OpenNTPD ...                                                                                                                                              [ ok ]
compile-local ~ # date
Sun 01 Sep 2019 08:02:34 AM -00
compile-local ~ #

Keep on reading!

using portage eix for the first time – cannot open database file

Installing “app-portage/eix” in Gentoo to manage your portage updates you might encounter this error, when trying to use “eix” for the first time:

Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')

The chances are missing directory “/var/cache/eix/” or the user:group of the “/var/cache/eix/” is root:root, which is NOT right.

The user:group must be “portage:portage”.

So the solution is really simple:

mkdir -p /var/cache/eix
chown portage:portage /var/cache/eix

Output – the errors you might get

Using the eix-sync failed with:

root@srv1 ~ # eix-sync 
 * eix-cache does not exist
 * Running eix-update
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')
 * eix-update failed
 * Time statistics:
     6 seconds for initial eix-update
     6 seconds total

Using the “eix-update” failed, too.

root@srv ~ # eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')

Output 2 – Successful update with eix

root@srv ~ # eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 167|167 (100) Finished             
[1] "myportage" /usr/local/myportage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign)
     Reading category 167|167 (100) Finished    
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
Database contains 19544 packages in 167 categories

Gentoo kde-frameworks/kdewebkit failed compilation with Qt5WebKit could not be found because dependency is required

Updating the KDE Plasma Desktop in our Gentoo workstations this time failed with

CMake Error at /usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:48 (find_package):
  Found package configuration file:

    /usr/lib64/cmake/Qt5WebKit/Qt5WebKitConfig.cmake

  but it set Qt5WebKit_FOUND to FALSE so package "Qt5WebKit" is considered to
  be NOT FOUND.  Reason given by package:

  Qt5WebKit could not be found because dependency is required to have exact
  version 5.11.x.

It was strange because the previous emerge included the QT upgrade from old 5.11.2 to 5.12.1 and this dependency should have been resolved properly before:

emerge -vau $(qlist -IC|grep dev-qt|sort|uniq)

But apparently despite that the emerge built all QT libraries in dependency order the “dev-qt/qtwebkit” was built against the old QT libraries. And this is what is saying the above error!

The solution is really simple just rebuild the dev-qt/qtwebkit

root@srv ~ # emerge -va dev-qt/qtwebkit

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

Calculating dependencies... done!
[ebuild   R    ] dev-qt/qtwebkit-5.212.0_pre20180120:5/5.212::gentoo  USE="X geolocation hyphen jit multimedia opengl printsupport qml -gles2 -gstreamer -nsplugin 
-orientation -webp" 0 KiB

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

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

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!

Access Violation error when compiling packets in Gentoo – symlink

Here is another example of Access violation error when building packages in Gentoo. This time the build process could not make a symbolic link in “/usr/bin” and the build process of the package failed with:

 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied

A detail explanation is available in our first article on the subject here – Access Violation error, when compiling packets in Gentoo.
All packages are built in a sandbox and there is a sandbox configuration in

/etc/sandbox.d/00default

, which instruct the build process where could write. If you get such error in 99.99% there is a bug in the package and if you do not want to wait for fixing it (report it!) you can manually edit the SANDBOX_WRITE variable and add the path, which causes the build failure. Build the package and remove the added path!!! Or you risk to make your system less secure!

We have problem with building the package “net-libs/srt-1.3.1”

srv1 src # emerge -v net-libs/srt

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

[ebuild  N     ] net-libs/srt-1.3.1::gentoo  USE="-doc -gnutls -libressl" ABI_X86="32 (64) (-x32)" 0 KiB

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

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) net-libs/srt-1.3.1::gentoo
 * srt-1.3.1.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                        [ ok ]
>>> Unpacking source...
.....
.....
>>> Install srt-1.3.1 into /var/tmp/portage/net-libs/srt-1.3.1/image/ category net-libs
 * abi_x86_32.x86: running multilib-minimal_abi_src_install
>>> Working in BUILD_DIR: "/var/tmp/portage/net-libs/srt-1.3.1/work/srt-1.3.1-abi_x86_32.x86"
make -j6 -l10 install 
[ 28%] Built target haicrypt_virtual
[ 40%] Built target srtsupport_virtual
[ 80%] Built target srt_virtual
[ 83%] Built target srt_static
[ 85%] Built target srt_shared
[ 90%] Built target srt-file-transmit
[ 95%] Built target srt-live-transmit
[100%] Built target srt-multiplex
Install the project...
-- Install configuration: "Gentoo"
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so.1.3.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.so
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/libsrt.a
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/version.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/logging_api.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/platform_sys.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt4udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/pkgconfig/haisrt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib32/pkgconfig/srt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied
-- Created symlink: /usr/bin/stransmit -> srt-live-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-ffplay
 * abi_x86_64.amd64: running multilib-minimal_abi_src_install
>>> Working in BUILD_DIR: "/var/tmp/portage/net-libs/srt-1.3.1/work/srt-1.3.1-abi_x86_64.amd64"
make -j6 -l10 install 
[ 11%] Built target srtsupport_virtual
[ 52%] Built target srt_virtual
[ 80%] Built target haicrypt_virtual
[ 83%] Built target srt_static
[ 85%] Built target srt_shared
[ 90%] Built target srt-multiplex
[ 95%] Built target srt-file-transmit
[100%] Built target srt-live-transmit
Install the project...
-- Install configuration: "Gentoo"
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so.1.3.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so.1
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.so
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/libsrt.a
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/version.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/logging_api.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/platform_sys.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/udt.h
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/include/srt/srt4udt.h
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/pkgconfig/haisrt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/lib64/pkgconfig/srt.pc
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-live-transmit
 * ACCESS DENIED:  symlink:      /usr/bin/stransmit
CMake Error: failed to create symbolic link '/usr/bin/stransmit': permission denied
-- Created symlink: /usr/bin/stransmit -> srt-live-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-file-transmit
-- Installing: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-multiplex
-- Up-to-date: /var/tmp/portage/net-libs/srt-1.3.1/image/usr/bin/srt-ffplay
>>> Completed installing srt-1.3.1 into /var/tmp/portage/net-libs/srt-1.3.1/image/

 * Final size of build directory: 14632 KiB (14.2 MiB)
 * Final size of installed tree:   5324 KiB ( 5.1 MiB)

 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/log/sandbox/sandbox-25570.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: symlink
S: deny
P: /usr/bin/stransmit
A: /usr/bin/stransmit
R: /usr/bin/stransmit
C: /usr/bin/cmake -E create_symlink srt-live-transmit /usr/bin/stransmit 

F: symlink
S: deny
P: /usr/bin/stransmit
A: /usr/bin/stransmit
R: /usr/bin/stransmit
C: /usr/bin/cmake -E create_symlink srt-live-transmit /usr/bin/stransmit 
 * --------------------------------------------------------------------------------

>>> Failed to emerge net-libs/srt-1.3.1, Log file:

>>>  '/var/tmp/portage/net-libs/srt-1.3.1/temp/build.log'

In the installation phase occurred the package failure leaving half installed package. So we edited the “/etc/sandbox.d/00default” and added “:/usr/bin” at the end of SANDBOX_WRITE:

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:/usr/bin"

Then rebuild the package with emerge and remove the added path “:/usr/bin”. This is a dirty workaround, but it will allow you to use srt (and as a dependency to another packages’ installation).

ffmpeg chroot jail from Gentoo linux (ffmpeg 4.1 with gcc 8.2)

Here we build a Gentoo ssh chroot jail. You may need this because

  • you want the bleeding edge versions of the video libraries like x264, x265, ffmpeg the latest version and so on.
  • latest version of GNU C library and the compiler GNU GCC (version 8.2) at the moment
  • use all the optimizations for compiling the ffmpeg and the libraries for you current processor. Use “-march=native”
  • you want just to be able to update your system and not to break your carefully compiled latest version ffmpeg
  • experiment with GCC compile flags
  • update and test in another directory by just copying the old chroot jail directory
  • no need of any additional software on the host (like virtualization lxc, docker, qemu, etc)
  • or you might want a 32bit version (why? really? but it is possible…)

Of course, you can use for the base any Linux system, but it is easy with Gentoo – the latest versions of almost all important libraries and a packet system, which builds everything for you after a little bit of first tuning…

So here is how to do it:
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!