Build error CentOS 8

[Fweeb]

Since there currently isn't a CentOS 8 build on the Klayout website, I've been trying to build it myself. I have the following packages installed for building:

• gcc
• gcc-g++
• qt5
• qt5-devel
• python3
• python3-devel
• ruby
• ruby-devel

Klayout builds fine if you build without Ruby using the -noruby flag. Unfortunately, that also means I can't run our DRC scripts. Trying to build with Ruby yields the following error:

gmake[2]: Entering directory '/home/builder/src/klayout-0.26.3/build-release/rba/rba'
g++ -c -pipe -std=c++0x -fvisibility=hidden -O2 -Wall -W -pedantic -Woverloaded-virtual -Wsign-promo -Wsynth -Wno-deprecated -Wno-long-long -Wno-strict-aliasing -Wno-deprecated-declarations -Wno-reserved-user-defined-literal -D_REENTRANT -fPIC -DHAVE_QTBINDINGS -DHAVE_PYTHON -DHAVE_RUBY -DHAVE_RUBY_VERSION_CODE=20505 -DHAVE_QT -DKLAYOUT_VERSION=0.26.3 -DKLAYOUT_VERSION_REV=LatestSourcePackage -DKLAYOUT_VERSION_DATE=2020-02-11 -DKLAYOUT_MAJOR_VERSION=0 -DKLAYOUT_MINOR_VERSION=26 -DKLAYOUT_TINY_VERSION=3 -DMAKE_RBA_LIBRARY -DQT_NO_DEBUG -DQT_DESIGNER_LIB -DQT_UIPLUGIN_LIB -DQT_PRINTSUPPORT_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GUI_LIB -DQT_XMLPATTERNS_LIB -DQT_NETWORK_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_CORE_LIB -I../../../src/rba/rba -I/home/builder/src/klayout-0.26.3/build-release/rba/rba -I../common -isystem /usr/include -isystem /usr/include -I../../../src/tl/tl -I../../../src/gsi/gsi -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtDesigner -isystem /usr/include/qt5/QtUiPlugin -isystem /usr/include/qt5/QtPrintSupport -isystem /usr/include/qt5/QtMultimediaWidgets -isystem /usr/include/qt5/QtSvg -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtMultimedia -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtXmlPatterns -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtXml -isystem /usr/include/qt5/QtSql -isystem /usr/include/qt5/QtCore -I/home/builder/src/klayout-0.26.3/build-release/rba/rba -isystem /usr/include/libdrm -I/usr/lib64/qt5/mkspecs/linux-g++ -o rba.o ../../../src/rba/rba/rba.cc
In file included from /usr/include/c++/8/ext/string_conversions.h:41,
                 from /usr/include/c++/8/bits/basic_string.h:6400,
                 from /usr/include/c++/8/string:52,
                 from ../../../src/tl/tl/tlInternational.h:29,
                 from ../../../src/gsi/gsi/gsi.h:36,
                 from ../../../src/gsi/gsi/gsiDecl.h:36,
                 from ../../../src/rba/rba/rba.cc:23:
/usr/include/c++/8/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.
gmake[2]: *** [Makefile:737: rba.o] Error 1
gmake[2]: Leaving directory '/home/builder/src/klayout-0.26.3/build-release/rba/rba'
gmake[1]: *** [Makefile:46: sub-rba-make_first] Error 2
gmake[1]: Leaving directory '/home/builder/src/klayout-0.26.3/build-release/rba'
gmake: *** [Makefile:485: sub-rba-make_first] Error 2

This seems awfully strange because stdlib.h is absolutely on this machine (in /usr/include). What am I missing here?

[Fweeb]

So I figured out a workaround for this. It turns out that in my case the issue was in the default QT5 config.

In /usr/lib64/qt5/mkspecs/common/gcc-base.conf, I had to change QMAKE_CFLAGS_ISYSTEM from -isystem to -I. Once I made that change, Klayout built like a champ and the Ruby bindings all work on my build. I'm not sure if this adjustment could (or should) be made in Klayout's build scripts rather than the system configuration, but at least now it seems that the situation is at least documented.

[bjacobs1]

I can confirm this on Fedora 31, both the succesful build with -noruby and the succesful build with the change in gcc-base.conf.

[klayoutmatthias]

Thanks for this information.

This means that #include <cstdlib> should not be used? I can easily revert to <stdlib.h>, but my reasoning was that <cstdlib> should be the C++ standard version.

Matthias

[bjacobs1]

Hi Matthias,

I tried to patch tlInternational.h, line 29, changing #include to #include "string", to no avail, and hence I don't think that's the problem. I think it has to do with the #include_next macro in combination with the -isystem flag. According to https://stackoverflow.com/questions/37218953/isystem-on-a-system-include-directory-causes-errors, -isystem adds a directory to the list of directories containing system headers, and also places it at the beginning. #include_next finds a header file depending on from which directory the macro is called (if I understood it correctly).

I'm not sure whose responsibility it is to fix this bug. It seems to be a system or QT issue. It is good to have a workaround available though, thanks Fweeb!

[klayoutmatthias]

I'm looking at this too ..

I see the problem is because the Ruby header location is coincident with the standard headers. Both are inside "/usr/include" on CentOS 8. qmake in it's unfathomable smartness will use "-isystem" for this purpose and hence spoil the system include hierarchy.

Essentially a cure could be to drop "RUBYINCLUDE" and "RUBYINCLUDE2" from the INCLUDEPATH in src/rba/rba/rba.pro if the value is "/usr/include". Not a nice solution though.

Matthias

[klayoutmatthias]

I think this build script patch should fix the issue:

index 7a8e95ee..7c9b9b74 100755
--- a/build.sh
+++ b/build.sh
@@ -587,6 +587,13 @@ $QMAKE -v
 # Force a minimum rebuild because of version info
 touch $CURR_DIR/src/version/version.h
 
+if [ "$RUBYINCLUDE" = "/usr/include" ]; then
+  RUBYINCLUDE=
+fi
+if [ "$RUBYINCLUDE2" = "/usr/include" ]; then
+  RUBYINCLUDE2=
+fi
+
 qmake_options=(
   -recursive
   CONFIG+="$CONFIG"

A more generic solution is appreciated. I think "/usr/include" and "/usr/local/include" need to be looked up. And PYTHONINCLUDE might need to be checked too.

Matthias

[klayoutmatthias]

BTW: I could not find qt5 and qt5-devel for CentOS 8. I had to pull them from the PowerTools repo. Do you have another source?

Matthias

[bjacobs1]

Hi Matthias,

I can confirm that the patch you proposed fixes the issue on my Fedora 31 system. As for the PYTHONINCLUDE variable, on my system, that points to a different directory, but this might not be the case on other users' systems.

Another solution might be to check for the default system dirs in the python/ruby snippets that you use to determine the respective include directories, or have small programs in place to determine the values of these variables, based on "gcc -xc -E -v -" and "gcc -xc++ -E -V -" (I'm sure other compilers have their own way of producing lists of the include directories used.) Those are not nice solutions either, but if everything was always nice and easy, build environments could figure out by themselves how to build a piece of software :).

Kind regards,
Bas Jacobs

[klayoutmatthias]

There is a regular RPM build now for CentOS 8. Downloads are available for master branch here: https://www.klayout.org/downloads/master/