Hi Caspar,
On 30/08/2018 21:31, Caspar van Leeuwen wrote:
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?
Well, the short answer is: it's easier to check where those binaries are
via 'which', because they could be either in $EBROOTGCC, $EBROOTGCCCORE
or $EBROOTBINUTILS...
In addition, we have Bazel easyconfigs that use the dummy toolchain, so
we still need a fallback to using 'which' anyway.
However, your example shows that this approach is not reliable, since we
may pick up wrappers rather than the actual binaries, this was
overlooked. So, we should fix this in the Bazel easyblock.
So, either we check first for $EBROOT* and fall back to 'which' (but
this will not fix your problem when Bazel is being built with the
'dummy' toolchain), or we come up with a reliable way to check whether
we're picking up the actual binary or a wrapper (one way that comes to
mind is checking the output of "file /path/to/gcc").
regards,
Kenneth
