Hi Kenneth, Thanks, I overlooked the part that it would be not completely clear *which* EBROOT you should check...
For the dummy toolchain, I wonder if there would even be a problem. I believe my problem comes from the fact that Bazel does some part of its installation with my GCCcore-6.4.0 libstdc++, then does a reset of the environment halfway (or at least I read something like this?) and then continues with my system libstdc++. Since my system libstdc++ only has older GLIBCXX versions, that fails. But, if you'd build with the dummy toolchain, wouldn't you in both cases you the same libstdc++ anyway - namely the system version? In that case, I'd not expect any problems to begin with, so do you even need to do those regex replacements for the dummy toolchain or can you just use the Bazel installscript 'as is'? Anyway, I have put this in as an issue for the EasyBlock and we can take it from there to look for a proper solution (https://github.com/easybuilders/easybuild-easyblocks/issues/1491). Cheers, Caspar ----- Original Message ----- From: "Kenneth Hoste" <[email protected]> To: "easybuild" <[email protected]>, "Caspar van Leeuwen" <[email protected]> Sent: Friday, 31 August, 2018 08:41:59 Subject: Re: [easybuild] Bazel-0.12.0-GCCcore-6.4.0 build issues 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
