Looks fine. -kto
On Jun 27, 2011, at 12:28 AM, David Holmes wrote: > 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
