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!

Missing pkg-config results in configure error: possibly undefined macro

This small article is for you who wonder why a configure script under Linux failed with an error like:

configure.ac:204: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:216: error: possibly undefined macro: AC_CHECK_LIB
configure.ac:328: error: possibly undefined macro: AC_CHECK_HEADER
autoreconf: /usr/bin/autoconf failed with exit status: 1
 FAILED 

So autoreconf failed with missing macros, but you just saw you had the latest version and no clue what is wrong with the code you tried to compile!
In most cases the problem is trivial – you are missing the

pkg-config

It is a helper tool used when compiling. It helps to have the correct compiler options and not to hard-coded them in your files. So search for this tool in your Linux distro and install it.

Under CentOS 7

yum install pkgconfig

Under Ubuntu/Debian

apt-get install pkg-config

Under Gentoo

emerge -v dev-util/pkgconfig

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.

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