Building root using a non-standard gcc path complains about __builtin_ia32_*

I’m absolutely certain that you’ve seen this issue before, but I can’t for the life of me find the answer to the problem.

I am trying to build root on a CentOS 6.8 machine using a gcc 4.8.2 module. Most of the build works out fine. When cling gets involved, however, I run into these __builtin errors:

core/utils/src/rootcling_tmp -f core/metautils/src/G__std__forward_list.cxx -s lib/libforward_listDict.pcm -m lib/libCore.pcm -rml libforward_listDict.so -rmf lib/libforward_listDict.rootmap -c forward_list /odysse
y/rc_admin/akitzmiller/fasrcsw/rpmbuild/SOURCES/root-6.08.06/core/metautils/src/forward_listLinkdef.h
In file included from input_line_9:9:
In file included from include/TApplication.h:33:
In file included from include/TQObject.h:41:
In file included from include/TString.h:41:
In file included from include/RStringView.h:26:
In file included from include/RWrap_libcpp_string_view.h:37:
In file included from /n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/…/…/…/…/include/c++/4.8.2/algorithm:62:
In file included from /n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/…/…/…/…/include/c++/4.8.2/bits/stl_algo.h:65:
In file included from /n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/…/…/…/…/include/c++/4.8.2/random:51:
In file included from /n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/…/…/…/…/include/c++/4.8.2/x86_64-redhat-linux-gnu/bits/opt_random.h:33:
In file included from /n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/include/x86intrin.h:27:
/n/sw/fasrcsw/apps/Core/gcc/4.8.2-fasrc01/lib64/gcc/x86_64-redhat-linux-gnu/4.8.2/include/ia32intrin.h:41:10: error: use of undeclared identifier ‘__builtin_ia32_bsrsi’
return __builtin_ia32_bsrsi (__X);
^

I’ve tried with both the configure and cmake builds to no avail. This was my most recent configure command (the environment variables are set by our module system):

./configure --with-gcc-toolchain=$GCC_HOME --with-python=$PYTHON_HOME/bin/python --with-fftw3-incdir=$FFTW_INCLUDE --with-fftw3-libdir=$FFTW_LIB --with-cfitsio-incdir=$CFITSIO_INCLUDE --with-cfitsio-libdir=$CFITSIO_LIB --with-cc=gcc --with-cxx=g++ --with-f77=gfortran

Hi,

It seems that you are passing conflicting options to the build script. For instance, --with-gcc-toolchain=$GCC_HOME probably conflicts with the gcc that gets found by using --with-cc=gcc --with-cxx=g++. Then at runtime the binaries cannot find the non-standard headers used at build time. Please try using only the first option for the gcc toolchain, and independently of this issue, please swtich to building with CMake instead of the classic build script, since it has been deprecated and may be removed from the repository in a future release.

If I only use the --with-gcc-toolchain option, it complains that --with-cc needs to be set. If I set them all explicitly to synonymous values, I still get the same error (even with a make distclean first).

I tried the cmake build and got the same result.

Have you tried to use only the --with-gcc option, but passing the full path to your non-standard compiler? I will have a look into the build system in the mean time to have a definitive answer for this, although I have not had this problem before even with compilers from non-standard locations.

Nope. I’ll give it a shot.

Based on the Googling that I’ve done, it seems like this has to do with LLVM / gcc conflicts. The functions that are a problem are gcc wrappers around builtins that gcc uses, but LLVM does not.

I get the same error if I drop the gcc-toolchain.

./configure --with-python=$PYTHON_HOME/bin/python --with-fftw3-incdir=$FFTW_INCLUDE --with-fftw3-libdir=$FFTW_LIB --with-cfitsio-incdir=$CFITSIO_INCLUDE --with-cfitsio-libdir=$CFITSIO_LIB --with-cc=$GCC_HOME/bin/gcc --with-cxx=$GCC_HOME/bin/g++ --with-f77=$GCC_HOME/bin/gfortran

Hi Aaron,

did you try building with CMake specifying the CC and CXX variables to point the build system to the compiler of your choice?
Configure/Make is deprecated in 6.10 and it would advisable in general to migrate away from it.

Cheers,
D

Oh, that’s right. I did not realize that the line giving you problems was a rootcling call, and not the regular compilation of ROOT. For low level architecture support, the headers distributed with each compiler usually defines some functions that are not implemented anywhere, but are part of the compiler implementation itself. That’s the case of the __builtin_ia32_* that you are seeing. These are just a method to direct the compiler to emit specific instructions on that architecture, usually SIMD instructions (those are the “functions” that the compiler intrinsics call). The problem is that rootcling, which uses llvm internally, does not understand the builtins from GCC headers. I am not sure what in particular is wrong with your configuration, though. As I said, I frequently use GCC compilers from non-standard locations, and never had such problems. The way I usually configure is with CC=/path/to/gcc CXX=/path/to/g++ cmake ... or cmake -DCMAKE_C_COMPILER=/path/to/gcc -DCMAKE_CXX_COMPILER=/path/to/g++ .... If you have not tried that, maybe it’s worth giving it a go. If you have problems with that too, there may be a problem either in the build system or with you non-standard compiler. Cheers,

Another thing, you may have a mismatch between 32bit and 64bit between your compiler and rootcling. Maybe check that as well and make sure you are compiling everything for x86_64 architecture.

No luck with -DCMAKE_C_COMPILER and -DCMAKE_CXX_COMPILER

I’m not really sure how to address this. I haven’t had to specify 64 v 32 bit in about 10 years :slight_smile:

If it helps, this is the list of modules that I have loaded. Most of them make sense- qpy is a python 2.7 module.

Currently Loaded Modules:

  1. gmp/6.0.0-fasrc01 5) cmake/3.5.2-fasrc01 9) automake/1.15-fasrc01 13) libxcb/1.11-fasrc01 17) cfitsio/3360-fasrc03
  2. mpfr/3.1.2-fasrc02 6) dri2proto/2.8-fasrc01 10) libtool/2.4.6-fasrc01 14) libxshmfence/1.2-fasrc01 18) fftw/3.3.4-fasrc08
  3. mpc/1.0.1-fasrc01 7) dri3proto/1.0-fasrc01 11) presentproto/1.0-fasrc01 15) libdrm/2.4.60-fasrc01 19) qpy/2.7.10-fasrc01
  4. gcc/4.8.2-fasrc01 8) autoconf/2.69-fasrc01 12) xcb-proto/1.11-fasrc01 16) Mesa/10.1.6-fasrc02

At least according to cmake, it’s picking up a 64 bit system.

– Found a 64bit system
– Found GNU compiler collection
– ROOT Platform: linux
– ROOT Architecture: linuxx8664gcc
– Build Type: RelWithDebInfo
– Compiler Flags: -pipe -m64 -Wshadow -Wall -W -Woverloaded-virtual -fsigned-char -fPIC -pthread -std=c++11 -O2 -g -DNDEBUG

There is something funny with your setup, like the compiler not being properly configured (independently of how you are trying to use it to compile ROOT). Can you give us more information about the exact commands you are using, where the compiler is installed, if you are on lxplus, etc. With only a few pieces it is very difficult to tell what is happening. Please paste below the output of uname -a and let us know if your glibc is 32bit or 64bit. It may as well be that you are on a 64bit processor, but running an entirely 32bit OS, in which case you’ll have to compile ROOT for 32bits as well. I see at the top that you are trying to compile ROOT 6.08/06, please move to ROOT 6.10.02 which was recently released if there is no blocker for you. You may have better luck with the new version. Also, I would recommend using at least GCC 4.8.5 or Clang 3.8 and above if you can.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.