Conversation
|
Has this patch been submitted upstream? |
|
There's a similar patch that's been submitted for Bazel 5+, but doesn't appear to have been backported to earlier releases. |
|
Can we use the exact same patch or is that not sufficient? Can you add a link to that patch so we have more context? |
| patch('disabledepcheck_old.patch', when='@0.3.0:0.3.1+nodepfail') | ||
|
|
||
| # include-what-you-use violation that snuck under the radar until GCC 11 | ||
| patch('ijar_limits_fix.patch', when='@0.3.2:5.0.0') |
There was a problem hiding this comment.
Version ranges as inclusive. If you want >= 0.3.2, < 5, that would look like 0.3.2:4
It's linked in my previous comment, but was insufficient. The other change I made has also been included in a different patch-set used by the Alpine Linux ports team, but I didn't test any of the other patches in that set as they were unnecessary for successful building on my machine. |
|
Is this a duplicate of #28548? |
|
Appears to overlap anyway. This applies a smaller set of patches more broadly. I did not need the other changes from the Alpine patch set to build the particular Bazel I cared about; however I can confirm that the patches in this PR are |
|
The patch in this PR is not sufficient for building bazel versions 4.1 to 4.2. |
|
Closing in favor of #28548 which includes these patches and more. |
|
@adamjstewart - After finally getting around to updating our Spack to 0.20.1, I can confirm that the patches introduced in #28548 do not resolve the issue with ijar assuming a transitive include of |
|
I believe the problem is that those patches should be unconditionally applied without checking GCC version because the existing code is demonstrably wrong, and other compilers (e.g. Clang) may use GCC system headers without identifying as GCC. |
|
Closing in favor of #40084. |
Looks like
<limits>was being transitively included somewhere until GCC restructured its header files with GCC 11.