Closed Kojoley closed 3 months ago
The PR appears to have exposed CI build environments not having been properly set up for 32 bit builds.
Was that the feature where address-model=32,64
would silently succeed and build everything twice for e.g. s390x that doesn't have 32 bit?
Was that the feature where
address-model=32,64
would silently succeed and build everything twice for e.g. s390x that doesn't have 32 bit?
Happy accident, as far as I can tell, like anytime when b2 silently ignores your inputs.
There is multiple issues with s390x:
1) address-model
on s390x is completely ignored.
2) s390x is like amd64/x86_64, for consistency with other architecture
s it should've been s390, but
3) IIUC GCC doesn't support generating code for s390, but it can generate code for s390 abi, something close to -mx32 on x86_64.
4) Clang/LLVM-based compiler for s390x is paywalled.
So it seems like it would not hurt to set -m31
on architecture=s390x address-model=32
.
There is also the same issue for riscv, but I don't know how to resolve it.
@grafikrobot is there a really need to ensure warnings-free build with architecture=32,64
on for every GCC and Clang out there?
Is this approach going to work for cross compilation scenarios?
Is this approach going to work for cross compilation scenarios?
Could you please expand on your question? You mean using gcc : : gcc-ppc64le-linux-gnu ;
b2 toolset=gcc address-model=32
or?
I can't come up with a scenario where this approach will fail, even using clang : : clang --target=ppc64le-linux-gnu ;
b2 toolset=clang address-model=32
or using clang : : clang --target=ppc64le-linux-gnu -m32 ;
b2 toolset=clang address-model=64
will do what you logically expect it should do (first will target powerpcle and second will target ppc64le).
I suppose that if you put the --target
option in user-config
it will be properly reflected by -dumpmachine
, yes.
@grafikrobot is there a really need to ensure warnings-free build with
architecture=32,64
on for every GCC and Clang out there?
It's caught some errors in the past. But I'm willing to change it. If you can offer some suggestions.
@grafikrobot is there a really need to ensure warnings-free build with
architecture=32,64
on for every GCC and Clang out there?It's caught some errors in the past. But I'm willing to change it. If you can offer some suggestions.
PS. The failures here for the no-warnings step are not because of warnings though. They appear to be real errors on first glance.
@grafikrobot is there a really need to ensure warnings-free build with
architecture=32,64
on for every GCC and Clang out there?It's caught some errors in the past. But I'm willing to change it. If you can offer some suggestions.
I mean... architecture=32
did nothing, so it would not catch anything.
What makes sense to me is to disable warning for bootstrap, and test for warnings only on recent compilers.
I also think there is no real users that install clang from llvm repository or gcc from ppa on ubuntu, especially on discontinued versions. I would only test default compiler on discontinued platforms and not bother with third-party repositories.
@grafikrobot is there a really need to ensure warnings-free build with
architecture=32,64
on for every GCC and Clang out there?It's caught some errors in the past. But I'm willing to change it. If you can offer some suggestions.
PS. The failures here for the no-warnings step are not because of warnings though. They appear to be real errors on first glance.
I stopped trying to understand what is needed to install for multilib clang on those failed jobs, but gcc<6 false-positive is there:
src/engine/jam.cpp: In function 'int guarded_main(int, char**)':
src/engine/jam.cpp:410:30: error: array subscript is below array bounds [-Werror=array-bounds]
globs.debug[ i-- ] = 1;
^
cc1plus: all warnings being treated as errors
My experiments show that Clang support -m32/-m64 universally (and doesn't support -m31 for s390), so I dropped GCC logic in it and just made Clang put -m flag solely on
@grafikrobot the change to azure scripts mostly no-op (dropping address-model=32,64
that were doing nothing before the patch). I've made Linux_Latest
to really perform address-model=32,64
.
Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce?
Put an
x
in the boxes that applyChecklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...