search

easybuilders / easybuild-easyblocks

Collection of easyblocks that implement support for building and installing software with EasyBuild.
https://easybuild.io
GNU General Public License v2.0
106 stars 283 forks source link

Bazel Easyblock fails when 'which gcc' points to wrappers #1491

Open casparvl opened 6 years ago

casparvl commented 6 years ago

Problem:

When building Bazel(-0.12.0-GCCcore-6.4.0), I get the error: 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.

Cause: As far as I understand, Bazel resets the environment somewhere during its installation. Thus, some of it is build with the GCCcore-6.4.0 libstdc++.so (with new version of GLIBCXX). Then, some environment reset takes place, and after that it picks up only the system libstdc++.so. The latter doesn't contain this newer GLIBCXX, hence the error.

The EasyBlock contains some logic to find the location of ar, cpp, dwp, gcc and ld and insert those in the Bazel installscript. This is intended to make sure you get the same environment (i.e. the same libstdc++.so) after this 'reset' that Bazel does. Since it relies on which to find the compiler, you get in trouble when using compiler wrappers:

== 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

Potential solution: Another way to find the compiler library path is needed. Problem is that it could be any of $EBROOTGCCCORE, $EBROOTGCC, $EBROOTBINUTILS (and potentially others) that would need to be used. Could it be an option to look for 'all' of those (and in which order)? And which ones should we check for? Or should we take another approach?

If we go for the EBROOT approach: what to do with the dummy toolchain? Is there even a problem for dummy? I would expect that dummy works fine with the default install script anyway, since it will use the libstdc++ in the default path (e.g. /usr/lib64).

boegel commented 6 years ago

Checking all of the listed $EBROOT* locations (if defined) is easiest, you shouldn't hit any "false positives" I think... You could make it more strict and only check for cpp/gcc in $EBROOTGCC(CORE), and only check for ar/dwp/ld in $EBROOTBINUTILS, but I'm not sure if it's worth the trouble to be intelligent about it.

For dummy we may need to be a bit careful... I'm not sure how well the hardcoded paths translate to different Linux distros for example. And since we do the search & replace now for dummy, we should keep doing that strictly speaking (to keep backward compatibility). We can make it optional for dummy though, so you get the freedom to disable that part of the easyblock.

You can also consider adding support in the Bazel easyblock to specify the location of these binaries, for example like this in the Bazel easyconfig:

ar_path = /usr/bin/ar

W.r.t. your wrappers: is Bazel with dummy still relevant? We only have one Bazel with dummy easyconfig, and it's quite old (and not used anywhere as dependency, as far as I can see). If not, just go with the $EBROOT* solution, and leave dummy as is (i.e. fall back to determining the location via which).