Project

General

Profile

Bug #23325

Root v6_16_00 not working in CentOS 7

Added by Cathal Sweeney 24 days ago. Updated 12 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
09/25/2019
Due date:
% Done:

0%

Estimated time:
Duration:

Description

Root v6_16_00 Linux64bit+3.10-2.17-e17-{debug|prof} gives the following error upon start-up:

root.exe: /scratch/workspace/canvas-products/vdevelop-/SLF7/e17-debug/build/root/v6_16_00/source/root-6.16.00/interpreter/llvm/src/tools/clang/include/clang/Serialization/Module.h:72: clang::serialization::InputFile::InputFile(const clang::FileEntry*, bool, bool): Assertion `!(isOverridden && isOutOfDate) && "an overridden cannot be out-of-date"' failed.

when using the following OS:

Distributor ID: CentOS
Description: CentOS Linux release 7.7.1908 (Core)
Release: 7.7.1908
Codename: Core

It seems to run without issue on the following SL7 distribution:

Distributor ID: Scientific
Description: Scientific Linux release 7.6 (Nitrogen)
Release: 7.6
Codename: Nitrogen

History

#1 Updated by Eric Flumerfelt 24 days ago

This is a known issue: https://sft.its.cern.ch/jira/browse/ROOT-10288

One possible workaround is to rebuild root v6_16_00 on the target machine.

cd <products directory>

curl https://scisoft.fnal.gov/scisoft/packages/root/v6_16_00/root-6.16.00-source.tar.bz2|tar -jxf -
./root/v6_16_00/build_root.sh $PWD e17 debug

#2 Updated by Christopher Backhouse 24 days ago

Does that issue imply that if we can get the SL7 copy of byteswap.h earlier in the include path than the system one it could work around the problem?

#3 Updated by Kyle Knoepfel 24 days ago

Chris, it may fix the problem, assuming the timestamp for that header is okay. But there are other headers that may have the same issue. Best bet is to just rebuild on the target machine.

#4 Updated by Kyle Knoepfel 19 days ago

  • Status changed from New to Feedback

Are you able to rebuild on the target machine?

#5 Updated by Christopher Backhouse 19 days ago

We're using a ups version of root, ultimately the one setup as a dependency of art, so building our own root is not very convenient in comparison.

#6 Updated by Christopher Green 12 days ago

Unfortunately, rebuilding ROOT on a CentOS or SL 7.7 machine is really the only sustainable option. SL 7.7 is currently in testing. When accepted, upgrading Jenkins machines to use it will be a solution, but not a short-timescale one. We can give details on how to do a practicallly-turnkey ROOT build on your system (or a similarly configured one) to produce a locally-built ROOT UPS package, if this would work for you. Build time would be 15-60 minutes, on a relatively-capable multi-code machine.

#7 Updated by Christopher Green 12 days ago

Please note: Eric's two-line instruction above is most of the way there. Assuming you wish to build a ROOT UPS product in a temporary place and then install it elsewhere:
  1. Ensure the relevant product stack is installed and accessible via PRODUCTS.
  2. Make a temporary products area:
    mkdir product-tmp
    cd product-tmp
  3. Initialize it from an existing UPS area:
    tar -C ${PRODUCTS%%:*} -c .upsfiles | tar xv
  4. Obtain the correct source tarball:
    curl -O -J -L --fail https://scisoft.fnal.gov/scisoft/packages/root/v6_16_00/root-6.16.00-source.tar.bz2 | \
      tar xj
  5. ...and build:
    ./root/v6_16_00/build_root.sh e17 debug tar
  6. Unwind the tarball in the location from which you wish to use it (removing the existing build first if necessary) and then remove product-tmp.

Building in a temporary area and then installing the tarball will take care of removing intermediate build products which are not part of the final build (object files, etc., etc.).



Also available in: Atom PDF