For the same reasons as detailed by bug 712718, bazel-0.27.2 fails to build against glibc-2.30. See also: https://github.com/bazelbuild/bazel/issues/8666 Note that the tensorflow-1.15.0 ebuild still requires either of =bazel-0.27* or =bazel-0.24*. I have not tested any other version of bazel than 0.27.2 but it is probable that this bug applies to some other versions presently carried by gentoo. As such, I would recommend testing them. I am attaching a patch extracted from https://github.com/clearlinux-pkgs/bazel/commit/adefd90. It can be applied by adding the following code to src_prepare: cd third_party/grpc || return eapply -p0 "${FILESDIR}/bazel-0.27-rename-gettid-functions.patch"
Created attachment 635224 [details, diff] bazel-0.27-rename-gettid-functions.patch
I assume this is fixed by now? Sorry I didn't see it.
(In reply to Sam James from comment #2) > I assume this is fixed by now? Sorry I didn't see it. Firstly, 0.27.2 still requires the patch, which I continue to carry in my repo. Secondly, ebuild versions 0.29.1, 1.2.0-r1 and 1.2.1 fetch the necessary patch as a distfile, before applying it. Thirdly, everything from 2.0.0 onwards should be unaffected. Therefore, it would be correct to carry out the following. * have 0.27.2 incorporate the patch * drop 1.2.0, leaving 1.2.0-r1 Regarding the first point, a revision bump seems appropriate, in line with how 1.2.0 was handled. It's probable that 0.22.0 and 0.24.0 will also need patching. I'll test those soon, assuming you don't get to it first.
(In reply to Kerin Millar from comment #3) > (In reply to Sam James from comment #2) > > I assume this is fixed by now? Sorry I didn't see it. > > Firstly, 0.27.2 still requires the patch, which I continue to carry in my > repo. Secondly, ebuild versions 0.29.1, 1.2.0-r1 and 1.2.1 fetch the > necessary patch as a distfile, before applying it. Thirdly, everything from > 2.0.0 onwards should be unaffected. I didn't realise you still needed 0.27.2/it was still useful, apologies! This is the problem when I'm going around doing cleanups for bugs not yet handled -- sometimes I end up touching things where I lack a bit of useful per-package context. > > Therefore, it would be correct to carry out the following. > > * have 0.27.2 incorporate the patch > * drop 1.2.0, leaving 1.2.0-r1 > > Regarding the first point, a revision bump seems appropriate, in line with > how 1.2.0 was handled. I'm wondering why - build time fixes don't normally require revision bumps, but you know that. I suppose it was a bit invasive though. > > It's probable that 0.22.0 and 0.24.0 will also need patching. I'll test > those soon, assuming you don't get to it first. If you don't mind, that'd be really helpful, as I'm currently running through GCC 11 blockers and soon, glibc-2.34. But if you need me to, just say. Ping me if I don't circle back to this. I'm glad to know you're OK, btw - I was considering emailing given absence from IRC to check.
(In reply to Sam James from comment #4) > (In reply to Kerin Millar from comment #3) > > (In reply to Sam James from comment #2) > If you don't mind, that'd be really helpful, as I'm currently running > through GCC 11 blockers and soon, glibc-2.34. But if you need me to, just > say. You must excuse me as I lack the presence of mind to coherently respond to the rest at this moment in time. As such, I'm only responding to say that I will gladly test the oldest two versions of bazel and shall do so at my earliest convenience.
Created attachment 739229 [details, diff] 0001-dev-util-bazel-glibc-2.30-and-gcc-11-compatibility-f.patch Having applied this patch, I am able to build all versions for the amd64 architecture, against glibc-2.33-r1 and gcc-11.2.0. Subject: [PATCH] dev-util/bazel: >=glibc-2.30 and gcc:11 compatibility fixes Ensure that versions 0.22.0, 0.24.1 and 0.27.2 are also patched so as not to conflict with glibc's gettid(2) function. Have all versions include the <limits> header, where required, for compatibility with gcc:11. Revise the dubious test for the presence of ccache so as to consider the value of FEATURES instead. Drop version 2.0.0 in favour of 2.0.1. Closes: https://bugs.gentoo.org/show_bug.cgi?id=720032 Closes: https://bugs.gentoo.org/show_bug.cgi?id=787248 Closes: https://bugs.gentoo.org/show_bug.cgi?id=808827 Signed-off-by: Kerin Millar <kfm@plushkava.net>
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4ee781d18fd2bbba3e78c70229f7aacd7d6c5a13 commit 4ee781d18fd2bbba3e78c70229f7aacd7d6c5a13 Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2021-09-14 03:48:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-09-19 01:38:16 +0000 dev-util/bazel: >=glibc-2.30 and gcc:11 compatibility fixes Ensure that versions 0.22.0, 0.24.1 and 0.27.2 are also patched so as not to conflict with glibc's gettid(2) function. Have all versions include the <limits> header, where required, for compatibility with gcc:11. Revise the dubious test for the presence of ccache so as to consider the value of FEATURES instead. Drop version 2.0.0 in favour of 2.0.1. Closes: https://bugs.gentoo.org/show_bug.cgi?id=720032 Closes: https://bugs.gentoo.org/show_bug.cgi?id=787248 Closes: https://bugs.gentoo.org/show_bug.cgi?id=808827 Signed-off-by: Kerin Millar <kfm@plushkava.net> Signed-off-by: Sam James <sam@gentoo.org> dev-util/bazel/Manifest | 5 +- dev-util/bazel/bazel-0.22.0.ebuild | 8 +- dev-util/bazel/bazel-0.24.1.ebuild | 8 +- dev-util/bazel/bazel-0.27.2.ebuild | 6 +- dev-util/bazel/bazel-0.29.1.ebuild | 15 ++- dev-util/bazel/bazel-1.0.1.ebuild | 8 +- dev-util/bazel/bazel-1.2.0-r1.ebuild | 114 ------------------- dev-util/bazel/bazel-1.2.1.ebuild | 13 +-- dev-util/bazel/bazel-2.0.0.ebuild | 109 ------------------ .../{bazel-1.2.0.ebuild => bazel-2.0.1.ebuild} | 7 +- dev-util/bazel/bazel-3.2.0.ebuild | 5 +- dev-util/bazel/bazel-3.7.2.ebuild | 5 +- .../bazel-0.22.0-include-limits-for-gcc-11.patch | 125 +++++++++++++++++++++ .../bazel-0.22.0-rename-gettid-functions.patch | 44 ++++++++ .../bazel-0.24.1-rename-gettid-functions.patch | 66 +++++++++++ .../bazel-3.2.0-include-limits-for-gcc-11.patch | 25 +++++ 16 files changed, 310 insertions(+), 253 deletions(-)
