Unpleasantly late ROOT 6.10.04 compilation error with GCC 7.1

Hi,

I’m trying to build ROOT 6.10.04 using GCC 7.1.1. Unfortunately, the build ultimately fails after a long while with the following error

[... lots of CMake build output ...]
[ 52%] Built target LLVMRES
[ 52%] Built target Dictgen
[ 52%] Built target rootcling_stage1
[ 52%] Generating G__Core.cxx, ../../lib/libCore.rootmap
In file included from input_line_4:1:
In file included from /home/hadrien/Software/ROOT/build-dir/include/Rtypes.h:185:
In file included from /home/hadrien/Software/ROOT/build-dir/include/TGenericClassInfo.h:16:
In file included from /home/hadrien/Software/ROOT/build-dir/include/TSchemaHelper.h:17:
In file included from /usr/include/c++/7/string:40:
In file included from /usr/include/c++/7/bits/char_traits.h:40:
In file included from /usr/include/c++/7/bits/postypes.h:40:
In file included from /usr/include/c++/7/cwchar:44:
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:105:1: error: unknown type name '__BEGIN_NAMESPACE_C99'
__BEGIN_NAMESPACE_C99
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:107:1: error: expected unqualified-id
typedef __mbstate_t mbstate_t;
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:108:1: error: unknown type name '__END_NAMESPACE_C99'
__END_NAMESPACE_C99
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:113:23: error: unknown type name 'mbstate_t'; did you mean '__mbstate_t'?
__USING_NAMESPACE_C99(mbstate_t)
                      ^
/usr/include/bits/types/__mbstate_t.h:21:3: note: '__mbstate_t' declared here
} __mbstate_t;
  ^
In file included from input_line_4:1:
In file included from /home/hadrien/Software/ROOT/build-dir/include/Rtypes.h:185:
In file included from /home/hadrien/Software/ROOT/build-dir/include/TGenericClassInfo.h:16:
In file included from /home/hadrien/Software/ROOT/build-dir/include/TSchemaHelper.h:17:
In file included from /usr/include/c++/7/string:40:
In file included from /usr/include/c++/7/bits/char_traits.h:40:
In file included from /usr/include/c++/7/bits/postypes.h:40:
In file included from /usr/include/c++/7/cwchar:44:
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:113:33: error: expected ';' after top level declarator
__USING_NAMESPACE_C99(mbstate_t)
                                ^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:135:1: error: unknown type name '__BEGIN_NAMESPACE_STD'
__BEGIN_NAMESPACE_STD
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:138:1: error: expected unqualified-id
struct tm;
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:139:1: error: unknown type name '__END_NAMESPACE_STD'
__END_NAMESPACE_STD
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:143:23: error: unknown type name 'tm'
__USING_NAMESPACE_STD(tm)
                      ^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:146:1: error: expected function body after function declarator
__BEGIN_NAMESPACE_STD
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:172:1: error: unknown type name '__END_NAMESPACE_STD'
__END_NAMESPACE_STD
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:176:1: error: expected unqualified-id
extern int wcscasecmp (const wchar_t *__s1, const wchar_t *__s2) __THROW;
^
/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:184:11: fatal error: 'xlocale.h' file not found
# include <xlocale.h>
          ^
Error: Error loading the default header files.
gmake[2]: *** [core/base/CMakeFiles/G__Core.dir/build.make:414: core/base/G__Core.cxx] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:14523: core/base/CMakeFiles/G__Core.dir/all] Error 2
gmake: *** [Makefile:152: all] Error 2

To my untrained eye, the mixture of “/usr/include/c++” and “/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/” paths in the error looks like some sort of include path issue that would make the two libc/libstdc++ variants of the system GCC and ROOT’s integrated Clang-based interpreter see each other and step on each other’s toes, ultimately causing the build to bomb because implementation details are not the same.

Now, in principle, I would be willing to spend extra time into understanding why exactly this build error is occurring. The problem is that these “Generating G__Something.cxx, …/…/lib/libSomething.rootmap” steps occur very late in the ROOT build process, and that I don’t want to wait half an hour for CMake to rebuild the entire ROOT/LLVM world whenever I try to touch a tiny bit of build configuration in order to see whether that changes anything or not.

So if someone already has experience with this kind of build issues and could help me get through them more quickly, it would be very helpful.

Please do not hesitate to ask me for any extra info you need (CMakeCache, system configuration, etc)

I think the CMakeCache would be useful. Which OS are you using? I can confirm that the build of ROOT 6.10.04 with gcc (MacPorts gcc7 7-20170622_1) 7.1.1 20170622 on Mac OS X 10.12.6 fails, but with a different error. (Not sure this is useful to your problem.)

...
[ 84%] Built target GuiHtml

CMake Error at TBB-stamp/TBB-download-RelWithDebInfo.cmake:16 (message):
  Command failed: 1

   '/opt/local/bin/cmake' '-Dmake=' '-Dconfig=' '-P' '/Users/user/programs/root/root-6.10.04/install-build-gcc7/TBB-prefix/src/TBB-stamp/TBB-download-RelWithDebInfo-impl.cmake'

  See also

    /Users/user/programs/root/root-6.10.04/install-build-gcc7/TBB-prefix/src/TBB-stamp/TBB-download-*.log


make[2]: *** [TBB-prefix/src/TBB-stamp/TBB-download] Error 1
make[1]: *** [CMakeFiles/TBB.dir/all] Error 2
make: *** [all] Error 2

Here is the output of TBB-download-err.log:

CMake Error at TBB-stamp/download-TBB.cmake:157 (message):
  Each download failed!

    error: downloading 'http://lcgpackages.web.cern.ch/lcgpackages/tarFiles/sources/tbb2017_U5.tar.gz' failed
         status_code: 22
         status_string: "HTTP response code said error"
         log:
         --- LOG BEGIN ---
           Trying [an IP address]...

  TCP_NODELAY set

  Connected to proxyout.awebserver.com ([an IP address]) port 8080 (#0)

  GET
  http://lcgpackages.web.cern.ch/lcgpackages/tarFiles/sources/tbb2017_U5.tar.gz
  HTTP/1.1^M

  Host: lcgpackages.web.cern.ch^M

  User-Agent: curl/7.55.0^M

  Accept: */*^M

  Proxy-Connection: Keep-Alive^M

  ^M

  The requested URL returned error: 404 Not Found

  Closing connection 0



         --- LOG END ---
1 Like

Here you go: CMakeCache.txt (122.2 KB)

I’m using openSUSE Tumbleweed, which is basically a rolling release flavor of SUSE Linux. Here is what gcc --version has to say:

gcc (SUSE Linux) 7.1.1 20170802 [gcc-7-branch revision 250825]

At first sight, our errors do not seem to be directly related. The “TBB-download” build task, if appropriately named, seems to be about downloading the Intel TBB library, whereas judging only from my error messages, the error that I am experiencing does not seems to be directly related to the use of TBB in ROOT.

Agreed, it does seem to indicate that gcc 7 is not yet completely supported by ROOT.

Let’s take a look at this error:

/home/hadrien/Software/ROOT/build-dir/etc/cling/lib/clang/3.9.0/include/wchar.h:184:11: fatal error: 'xlocale.h' file not found
# include <xlocale.h>
          ^
Error: Error loading the default header files.

Do you have this header? or do you instead have locale.h?

I have a header named like that, but it lies in a pretty strange path. I also have a locale.h header in a more reasonable place.

hadrien@linux-2ak3:~> find /usr/include/ -name xlocale.h
/usr/include/c++/v1/support/ibm/xlocale.h
/usr/include/c++/v1/support/musl/xlocale.h
/usr/include/c++/v1/support/newlib/xlocale.h
/usr/include/c++/v1/support/solaris/xlocale.h
/usr/include/c++/v1/support/xlocale/xlocale.h
hadrien@linux-2ak3:~> find /usr/include -name locale.h
/usr/include/bits/locale.h
/usr/include/c++/v1/locale.h
/usr/include/locale.h

(From a look at your error, it looks like this TBB-download script is trying to download some TBB sources package that doesn’t exist anymore and should probably be updated to point to the proper URL. I would gladly give you a fixed URL myself, but it looks like a paranoid person disabled the web server’s ability to list the contents of the directory @ https://lcgpackages.web.cern.ch/lcgpackages/tarFiles/sources/ :wink: )

Looks like all your problems stem from your gcc distribution. The CMake file shipped with ROOT copies the wchar.h file from your distribution before compilation (core/clingutils/CMakeLists.txt):

# These headers do not have complete include guards on all platforms we
# support. This means that the PCH cannot provide their representation at
# runtime and clang will hit disk, triggering a possible incompatibility
# of that file in build-time versus run-time (different length etc).
# Capture their build-time version here, and inject it into runtime.
foreach(file wchar.h bits/stat.h bits/time.h)
  if(EXISTS /usr/include/${file})
    list(APPEND copy_commands COMMAND ${CMAKE_COMMAND} -E copy /usr/include/${file} ${CMAKE_BINARY_DIR}/etc/cling/lib/clang/${LLVM_VERSION}/include/${file})
  endif()
endforeach()

Maybe you have clashing gcc packages? (EDIT: This was the issue with OP.) Have you tried building something simple that use the string header?

Could you provide the output of your TBB-prefix/src/TBB-stamp/TBB-download-out.log to see where you downloaded it from?

I can build and run something that includes wchar.h (without using it though) just fine:

hadrien@linux-2ak3:~> cat test.c
#include <stdio.h>
#include <wchar.h>

int main() {
  printf("Oh yeah!\n");
  return 0;
}
hadrien@linux-2ak3:~> gcc test.c
hadrien@linux-2ak3:~> ./a.out 
Oh yeah!

On the other hand, your comments give me an idea of something else that could go wrong. For historical reasons (troubleshooting clang-specific issues), I have both GCC and clang installed. And usually, the two cohabitate just fine. But maybe the ROOT build scripts do not expect two different compilers to be around at the same time and get completely confused… Hmm…

Let me try to uninstall the clang package, which I don’t need at the moment, and rebuild the thing, just in case this solves the problem.

As for the TBB-prefix folder, I don’t have one. I suspect that this is because I use the system TBB package instead of letting ROOT build its own.

You used the c compiler and not the c++ compiler, I’m not sure there will be much difference.

You might actually do a diff between the ROOT copied wchar.h and the others.

I spontaneously went for a C compiler since wchar.h is a C-ish header naming convention. But since almost every valid C program is a valid C++ program, it’s not difficult to check that g++ also likes this example:

hadrien@linux-2ak3:~> rm a.out && g++ test.c && ./a.out
Oh yeah!

Just started a rebuild without clang and its libc++ installed, and it already went past the previously crashing “Generating G__Core.cxx, …/…/lib/libCore.rootmap” step. This looks promising!

EDIT: It builds! It installs! It runs! Wonderful!

Should I report this intolerance of multiple libc implementations as a ROOT build system bug, or is that an expected build failure scenario?

Very good. I would not expect this is a bug exactly, if you install conflicting packages this kind of thing is bound to happen at some point. I’ll leave it to the ROOT group to make that decision whether this is indeed a build error. At last you have understood the issue.

I started another thread to discuss my issue:

Yup, thanks for the help in figuring this out. I’ll leave it up to the ROOT team to decide on this, as far as I’m concerned the most pressing issue is fixed :slight_smile:

The problem is that http://lcgpackages.web.cern.ch is down, so try with system versions of the libraries that are currently downloaded for you. The repository should be back online soon.

1 Like

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