On 2023-12-11 10:24, Andrew Haley wrote:
On 12/8/23 20:36, erik.joels...@oracle.com wrote:
On 12/8/23 08:29, Magnus Ihse Bursie wrote:
OK. So you are doing what I'd usually call cross compiling, sort
of, but
you don't want to treat it as a cross-compiled build. It's an unusual
case, in that it is cross compiled, but it is also expected to be
able to
run on the build system.
The main reason for the build to know if we're doing a
cross-compilation or not has been if we need a special compiler to
create build tools. For me, that is in essence what the
cross-compilation flag is saying.
>
I think the issue now is that automatically figuring out if a separate
compiler is needed or not can be hard. We do it in some cases, but not
in others, and sometimes we get it wrong (as in the linux-aarch64 issue
Mikael recently fixed, where the given tuple didn't exactly match what
config.guess found on the build machine). I think it would be reasonable
to have a configure parameter to control this explicitly.
I think so, or to be able to override what the build system deduces from
other build parameters.
Like everything else in configure, we should try to make automatic
deduction of sane default values, but allow the user to override
completely if necessary.
So maybe we should have like "cross-compiling-need-build-compiler" and
"cross-complining-can-use-target-compiler"?
Not sure of the naming here, but in essence, that's where we are making
implicit assumptions today that are hard to control.
If you specify --with-openjdk-target and the tuple is different than the
build tuple, then we can assume the default is to need a build compiler,
but there are cases where that is still not strictly needed. If
--with-build-devkit is supplied, then that is also a good indication as
we are given an explicit build compiler. Just supplying a sysroot/devkit
should probably not be assumed as needing a build compiler, but paired
with a suitable option, this could support the cross compile to EL8 from
EL7. I could for instance imagine setting --with-build-sysroot=/ to help
nudge configure into defining a separate build compiler, but maybe
that's too clunky?
Maybe, or at least fails the principle of least surprise. I think I may
be missing something important here: what is the downside of treating a
build as a cross compilation? Is it simply that more work has to be done,
or something else?
The real downside is if we decide that we need a build jdk, then we need
to build the JDK twice. Apart from that, I think it is mostly that it
complicates the configuration.
I'm trying to imagine what would happen if we say we are doing a
cross-compile but set the sysroot to /, and set the build toolchain and
the target toolchain to the same native tools. I don't think there would
be any other negative effects.
But maybe I'm forgetting something...
/Magnus
