Cross-compiling and the gen* native build tools
Martin Buchholz
martinrb at google.com
Tue Feb 4 04:17:52 UTC 2014
A strategy that often works is to just use the preprocessor output instead
of compiling and running the resulting program. autoconf has support for
this.
http://www.gnu.org/software/autoconf/manual/autoconf.html#Running-the-Preprocessor
On Mon, Feb 3, 2014 at 6:13 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:
> I just noticed this when replying to a mail to Volker, but I think this is
> worth a thread on it's own.
>
> There are three very similar build helpers that are compiler with
> BUILD_CC, i.e. the compiler for the build (not target) platform. They are:
>
> jdk/src/solaris/native/sun/nio/fs/genUnixConstants.c
> jdk/src/solaris/native/sun/nio/fs/genSolarisConstants.c
> jdk/src/share/native/sun/nio/ch/genSocketOptionRegistry.c
>
> They are very similar in that they pick up (build) platform constants and
> turn them into Java constants.
>
> This does not work for cross-compilation, so we have closed sources
> hard-coded versions for these platform we internally cross-compile to.
>
> This does not strike me as a neat solution. You can't add a new target to
> cross compile to without mimicking our internal closed code structure. You
> are always needed to provide a build platform compiler, even though the
> results are not supposed to change for the platform you're building for.
> (If it were, then the resulting code would not be possible to run on any
> other platform then your own, i.e. it wouldn't be constants).
>
> I think we should do something similar to with the X11 wrappers, and
> hard-code the values, with a possible, optional, verification step.
>
> /Magnus
>
More information about the build-dev
mailing list