configure_make: support autotools cross-compilation #1247
Conversation
novas0x2a
force-pushed
the
autotools-xcompile
branch
2 times, most recently
from
95620ea to
389ea88
Compare
|
|
||
| install_cmd = ["./make install"] | ||
|
|
||
| xcompile_options = detect_xcompile(ctx) |
There was a problem hiding this comment.
This all looks correct but when does the built make tool (or pkgconfig?) ever get cross compiled? I would have thought that it was always in the exec configuration and so would always be built natively?
There was a problem hiding this comment.
In rfcc that's true, but due to annoying historical reasons, we build make for both the exec and the target. For autoconf, anything that doesn't do the --host thing when cross-compiling causes it to just break, so I defaulted to adding it everywhere that used autotools (we don't build pkg-config for the target, I was just being consistent to minimize surprise)
| elif os == "macos": | ||
| if arch == "aarch64": | ||
| return "aarch64-apple-macos" | ||
| elif arch == "x86_64": | ||
| return "x86_64-apple-macos" |
There was a problem hiding this comment.
Is macos correct? On my mac at least the triplet names used for gcc installed via homebrew are aarch64-apple-darwin23
There was a problem hiding this comment.
Yeah, the convention for homebrew is ${arch}-apple-darwin${version}. Other examples we saw internally (from running config.guess on those platforms) were (aarch64|x86_64)-apple-darwin23.(4|5).0 and I was slightly nervous about lying about the library version, so I checked to see what config.sub would do (since that's what autotools uses to normalize) and it uses macos as the default os name, but then also preserves the darwinXX when it sees it:
$ ./config.sub-63acb96f92473ceb5e21d873d7c0aee266b3d6d3 aarch64-apple-macos
aarch64-apple-macos
$ ./config.sub-63acb96f92473ceb5e21d873d7c0aee266b3d6d3 aarch64-apple
aarch64-apple-macos
$ ./config.sub-63acb96f92473ceb5e21d873d7c0aee266b3d6d3 aarch64-apple-darwin123
aarch64-apple-darwin123
I took this as a sign that macos was fine. A slightly more correct way to guess the host might actually be to ship config.guess and run it as an action to see what it says, and then use that, but since there's no good way to do that reliably for the target tuple, I biased towards internally-consistent normalization.
One other consideration is, I don't currently pass --build, just --host. This means it's possible that autoconf's cross_compiling flag will get set to true when it shouldn't be (like in the darwin case above). I did that because it's more likely to result in a working result when the target's not in our tuple, but it does also mean passing --host aarch64-apple-darwin23 when config.guess thinks it's aarch64-apple-darwin23.4 triggers cross-compiling mode. The fix for this would be to pass both --host and --build all the time, so our consistent normalization prevents that from being a problem. (I did confirm this in our CI, our darwin builds do end up emitting checking whether we are cross compiling... yes)
I'm happy to adjust this to whichever variation you think is best! After having written this out, I'm actually more inclined to pass --build under every scenario we pass --host and rely on other users updating the data as-needed, but I'll defer to you.
There was a problem hiding this comment.
I did think of a disadvantage of passing --build: there's no way (that I know of) for bazel to guess which libc the compiler is expecting, because there aren't consistent libc constraints to use. I don't think this actually breaks anything, though, because it appears that when autoconf finds musl it actually internally replaces the triplet with gnu anyway.
I think I'll make the change anyway (it can't break any existing code because autotools would already be breaking in that case) but just something to keep an eye on.
Mentioned in the review comments above, but I ended up running this in our darwin CI and it worked. |
novas0x2a
force-pushed
the
autotools-xcompile
branch
2 times, most recently
from
920c1d6 to
95cc3b1
Compare
|
I pushed a new version with a few fixes, including fixing two brown-paper-bag fixes (I had two bugs that cancelled each other out, that I've now fixed) |
This teaches the autotools-based configure script to pass --host when cross-compilation is detected. This fixes at least part of bazel-contrib#1082. This functionality is off by default (because configure_make can be used for non-autotools builds) and can be enabled by passing configure_xcompile to configure_make. This functionality is also extended to the built_tools that use autoconf (pkg-config and make). It also does a bit of generalization to make it easier to support more platforms in the future, and adds s390x to the detected arches.
novas0x2a
force-pushed
the
autotools-xcompile
branch
from
95cc3b1 to
41df368
Compare
|
@novas0x2a could you add a brief example here of how to use I might make another PR to add the |
Looks like the docs generation hasn't run yet, but, the version that landed just has a bool,
It'd need to match the upstream tokens: |
They are there: https://github.com/bazelbuild/platforms/blob/main/os/BUILD#L110 |
This teaches the autotools-based configure script to pass --host when
cross-compilation is detected. This fixes at least part of #1082. This
functionality is off by default (because configure_make can be used for
non-autotools builds) and can be enabled by passing configure_xcompile
to configure_make.
This functionality is also extended to the built_tools that use autoconf
(pkg-config and make).
It also does a bit of generalization to make it easier to support more
platforms in the future, and adds s390x to the detected arches.