Thanks Kelly. Updated webrev at:
http://cr.openjdk.java.net/~dholmes/7039182/webrev.1/
David
Kelly O'Hair said the following on 06/23/11 02:35:
Things like this:
884 $(SFS_GEN)/SolarisConstants.java:
885 $(prep-target)
886 $(CP)
$(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/fs/SolarisConstants-$(PLATFORM)-$(ARCH).java
$@
Should be written as:
884
$(SFS_GEN)/SolarisConstants.java: $(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/fs/SolarisConstants-$(PLATFORM)-$(ARCH).java
885 $(prep-target)
886 $(CP) $< $@
-kto
On Jun 16, 2011, at 10:03 PM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/7039182/webrev/
This will be pushed through the TL jdk repo but Alan suggested getting
build-dev to review (in addition to himself).
This isn't a public bug so I'll describe the issue.
When the NIO libs are built there are a few files that contain
constants that represent platform specific I/O constants found in
various C header files. Normally the build process compiles and runs a
small C program which will generate the .java file for that platform.
When I integrated the basic support for cross-compilation I modified
this process to use the host C compiler not the cross-compiler for the
target, as we couldn't execute the resulting C program. That wasn't
the correct thing to do because it means we generate values for the
build platform not the target platform. Luckily these values are
mostly the same on the Linux platforms we care about, but not all the
same (hence this bug report where a read system call returned EINVAL
because we thought we were passing O_NOFOLLOW but in fact passed
O_DIRECT).
The simplest fix is to not try to generate a file when cross-compiling
but allow the developer to specify where these files can be found.
This is done using the NIO_PLATFORM_CLASSES_ROOT_DIR variable which is
expected to be the "root" directory for where classes can be found and
the directories under that are expected to follow the package
hierarchy for the files, so, for example we will look for:
$(NIO_PLATFORM_CLASSES_ROOT_DIR)/sun/nio/ch/SocketOptionRegistry-$(PLATFORM)-$(ARCH).java
the platform and arch are used in the filename as we don't have
platform/arch directories in the JDK repo.
In addition I reverted the original change to use the host C compiler
as this allows you to specifically build the generator program using
the cross-compiler (which will get the right values) then copy it
across to the target system and run it to generate the file.
For SE-Embedded we need to set NIO_PLATFORM_CLASSES_ROOT_DIR to point
into the "closed" platform sources.
Thanks,
David Holmes
