Dear all, I get an error when building Bazel-0.12.0:
bazel-out/host/bin/external/io_bazel/third_party/protobuf/3.4.0/js_embed: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bazel-out/host/bin/external/io_bazel/third_party/protobuf/3.4.0/js_embed) As you can see, it picks up the system libstdc++, rather than the GCCcore-6.4.0 one. The Bazel EasyBlock seems to search for the location of five tools: ar, cpp, dwp, gcc and ld. == 2018-08-30 13:28:35,003 easyblock.py:2536 INFO Running method configure_step part of step configure == 2018-08-30 13:28:35,023 filetools.py:343 INFO Command ar found at /hpc/sw_test/EB_regression/software/binutils/2.28-GCCcore-6.4.0/bin/ar == 2018-08-30 13:28:35,025 filetools.py:343 INFO Command cpp found at /hpc/sw_test/EB_regression/software/GCCcore/6.4.0/bin/cpp == 2018-08-30 13:28:35,027 filetools.py:343 INFO Command dwp found at /hpc/sw_test/EB_regression/software/binutils/2.28-GCCcore-6.4.0/bin/dwp == 2018-08-30 13:28:35,028 filetools.py:343 INFO Command gcc found at /scratch-shared/jenkins/regression/tmp/eb-JpFDuQ/tmpzLIai8/rpath_wrappers/gcc_wrapper/gcc == 2018-08-30 13:28:35,029 filetools.py:343 INFO Command ld found at /scratch-shared/jenkins/regression/tmp/eb-JpFDuQ/tmpzLIai8/rpath_wrappers/ld_wrapper/ld >From what I understand from the EasyBlock, this is used to overwrite some info >in Bazel's installscripts. However, it picks up on our compiler wrappers, >rather than the actual gcc. My assumption is that somehow, the location of those tools is used to infer the location of the GCC that use used, and hence inject the correct lib-path for thát GCC, so that Bazel picks up on e.g. the correct libstc++. Is there anyone who has experience with the Bazel EasyBlock that can confirm that theory? And how should I solve this? I'm a bit surprised the EasyBlock relies on the location of gcc, even though in EasyBuild we have stuff like EBROOTGCCCORE that could have been used. Any reason why that approach was not taken? Best regards, Caspar van Leeuwen SURFsara
