Hi Erik,

Thanks for your kind response!

在 2019/1/25 上午1:19, Erik Joelsson 写道:
Hello,

I agree with the conclusion here, there is certainly a bug in the build logic. When creating the "Build JDK" during a cross compilation build, we are, as Magnus said, cutting a few corners for efficiency. One of those corners is assuming all the java classes are the same and can simply be reused. It has been shown here that that assumption is not always correct.

I think the most reasonable solution is to assume all of java.base needs to be built specifically for the "Build JDK". I think this can be reasonably easy to implement (compared to the existing Build JDK logic, which is arguably rather hairy).

Magnus' suggested workaround should work fine for now however.

Failed to make images https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024765.html

But please point out my fault, thanks a lot!




Filed https://bugs.openjdk.java.net/browse/JDK-8217739

Thanks for your bug report!

Regards,

Leslie Zhai




/Erik

On 2019-01-24 05:30, Magnus Ihse Bursie wrote:
On 2019-01-24 13:22, Leslie Zhai wrote:
Hi Magnus,

Thanks for your kind response!

在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:


On 2019-01-24 05:45, David Holmes wrote:
On 24/01/2019 1:51 pm, Ao Qi wrote:
Hi David,

On Thu, Jan 24, 2019 at 10:47 AM David Holmes <david.hol...@oracle.com> wrote:

Hi Leslie,

I'm not Erik :) however ....

On 24/01/2019 12:28 pm, Leslie Zhai wrote:
Hi Erik,

Because the flags' macro of MIPS is different from other targets[1], it
will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different
from other targets.  Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].

It's been quite a while since we built for a platform where the flags had different values, but it is supposed to work. I suspect that the way we build now with the module system may not be quite correct in this regard - but that is just supposition on my part. Because compile-time constants are stored directly into class files that use them, we have to generate UnixConstants.java before compiling any class that needs to use it, then we must compile all classes that do use it. Those classes must
only be executed in conjunction with a tool executing on the target
platform (javac, jmod etc). My suspicion is that we may be executing a
tool on the build platform using the newly compiled classes for the
target platform - and that would be wrong.


Yes. Some variables in UnixConstants.java is defined according to the
target (fcntl.h of mips in this case), but would be executed on host
(x86 in this case) during "make images". These variables of ppc64le,
aarch64 and s390x are the same as x86, but the ones of mips are not.
However, mips is not an official supported target and I did not find
other targets have similar issue, I am not sure if this is a bug or if
this is the right mailing list :)

This is the right mailing list to discuss. :)

So I went back to find when this happened in the past and I mis-remembered how we solved it. We previously had a problem with the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 platforms defined a different value for the O_NOFOLLOW and O_DIRECT flags. The solution then was to commit a platform specific version of UnixConstants.java and change the build system to only use the template file if there was not a pre-existing .java file. But that platform and the SE Embedded support was all removed. (SocketOptions.java had a similar problem.) Further that build logic is completely different to what we had back then (JDK 6/7).

This is definitely a bug in our build logic IMHO as we specifically use the build platform c-pre-processor to process the template file based on the target header files, but then use the resulting class when running tools on the build platform.
I agree with David. This is a bug in the build system; arguably even a regression.

This was not something that happened in 6/7 or even 8 and I think the module system tools are where the issue now lies.

I think Erik and/or Magnus will have to give advice on how this may be properly fixed. I can't see any simple solution.
Unfortunately, I also agree that there is no simple solution. :-(

The proper way to handle this is to generate two versions of UnixConstants and friends, one for the build platform, and one for the target platform. But as far as I know, there is no simple way to handle such complications in our current structure. Erik knows more about this, he was the one who designed the current solution for handling cross-compilation in the modularized world.

However, I can at least help you with a relatively simple workaround. First some background: When we cross-compile, we need not only a Boot JDK (of version current N-1) running on the build host platform, but we also need a Build JDK, based on the current source code, running on the build host. (This is for running jmod/jlink; it needs to be up to date). If we have no Build JDK present, we start by creating one ourselves. This is more or less the same output as running a normal, non-cross compiled, build on the build host. (But Erik found some ways to cut a few corners to save time.) Your problem is that the Build JDK is broken, since UnixConstants has the wrong values.
-
But you can supply your own working Build JDK to configure!

So, your workflow for cross-compiling to MIPS should be:
1) create a Build JDK, e.g. like this: "bash configure --with-conf-name=buildjdk && make jdk CONF=buildjdk" 2) create your cross-compilation JDK like this: "bash configure --openjdk-target=mipsel-unknown-linux-gnu --with-build-jdk=build/buildjdk/jdk"
... or something like that.
Then you can build your cross-compiled jdk with "make images CONF=mips".

I will try that, thanks a lot for your teaching!
Please let me know if it works. I wrote the command lines out of my head, so they might need some tweaking to get right.

Perhaps this is an acceptable solution to you? Unless Erik can suggest ways to fix this properly that is not too complicated, maybe this can be a good enough solution for you? (But if there is a simple solution, I'd rather have it fixed properly.)

/Magnus

Regards,

Leslie Zhai




In theory, you should rebuild your buildjdk for each and every change ("make jdk CONF=buildjdk && make images CONF=mips"); but in reality, I don't believe there is really any need to rebuild the buildjdk (unless major changes in jlink/jmod happens).

/Magnus

David
-----

  For example:

jdk/build$ find . -name UnixConstants.java | xargs grep -A2 O_APPEND
./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-ppc64le-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000
--
./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-x86_64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000
--
./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-s390x-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000
--
./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-aarch64-server-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000
--
./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-x86_64-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000
--
./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-mips64el-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      0x0008
--
./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java:
    static final int O_APPEND =
./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java- ./linux-ppc64le-zero-release/support/gensrc/java.base/sun/nio/fs/UnixConstants.java-
                                      02000

log.mips:2of path:
/home/loongson/aoqi/jdk-mips/build/linux-mips64el-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp
oflags: 769 O_TRUNC:512 O_APPEND:8 O_CREAT:256 O_EXCL:1024
log.ppc:2of path:
/home/loongson/aoqi/jdk-mips/build/linux-ppc64le-normal-server-release/support/interim-jmods/temp/.java.base.jmod.tmp
oflags: 577 O_TRUNC:512 O_APPEND:1024 O_CREAT:64 O_EXCL:128

Cheers,
Ao Qi





Reply via email to