Happy to see subject back to technical. If you take a closer look to patch, you'll see universal is enforced as ARCH.
More on this tomorrow. Le 10 mai 2012 à 20:29, Scott Kovatch <[email protected]> a écrit : > > On May 10, 2012, at 11:19 AM, Michael McMahon wrote: > >> On 10/05/12 18:35, Scott Kovatch wrote: >>> On May 10, 2012, at 8:51 AM, Dalibor Topic wrote: >>> >>>> On 5/10/12 5:21 PM, Mike Swingler wrote: >>>>> The OpenJDK product should be build-able for 32 or 32/64 Universal by >>>>> anyone else, and should accept contributions to it's maintenance, but if >>>>> nobody is signing up to keep forward-porting the changes - they don't >>>>> have a future. >>>>> >>>>> Am I missing something here? >>>> That's why I'm asking the questions. I want to know what to expect - >>>> a single patch for some or other build issue, a full porting effort, >>>> or something else entirely. >>> Maybe what would help here is for someone to write a specification of what >>> we want to have happen. I don't want to put words in Henri's mouth, but I >>> feel he is assuming that everyone in the OpenJDK community is fully aware >>> of what Apple did with the JDK, and in my time here it's clear that this is >>> not the case. Being able to run a 32-bit JVM was a useful feature. If >>> someone wants to continue to do that, Oracle should not make it impossible >>> because we don't want to support it. This should be nothing more than a >>> build issue. If someone wants to build x86_64 or a 'universal' build, we >>> shouldn't block that. >>> >>> Let's make it clear once and for all what is desired. I can put this into a >>> bug if it will help. >>> >>> -- A straight 'make' of OpenJDK on Mac OS X is 64-bit only. '-d32' and >>> '-d64' are ignored. >>> -- 'make all_xxx_universal' produces a universal build. (Some clarification >>> on the make target would be helpful) >>> -- All versions of Mac OS X that support 64-bit Intel allow you to run >>> binaries of either architecture. If the build is universal, passing '-d32' >>> or '-d64' on the command line chooses the architecture to be run. >>> -- When -d32 is used, System.getProperty("os.arch") = "i386". Any native >>> libraries loaded must be i386. >>> -- When -d64 is used, System.getProperty("os.arch") = "x86_64". Any native >>> libraries loaded must be x86_64. >>> -- We will not support an i386-only build. If someone wants to fork or add >>> a post-processing step that lipo's away all of the x86_64 parts, they can >>> do that. >>> >>> As far as maintenance goes: >>> >>> -- No patch that compiles with only one architecture is allowed. >>> -- By extension, no linking against a framework or library that is 32-bit >>> or 64-bit only. >>> -- At some well-defined time in the future we will drop i386 entirely, but >>> not before OS X is completely 32-bit-free. (Yes, this is strict. If you >>> want to do something that is i386-only, fork the project.) >>> >>> Are there any points I'm missing here? Henri, does your patch satisfy all >>> of these requirements? I think it does, based on the conversation I saw >>> between you and David Holmes, but I'm not clear on the make targets. >> I'd agree with the above, though it would be nice if some existing build >> variable >> like ARCH_DATA_MODEL could be used to signify the universal build, rather >> than introducing >> a new make target. > > I thought we already had universal make targets, based on Henri's patch… but > now I see that's in hotspot only. > > Henri, how are you triggering a universal JDK build? With ARCH_DATA_MODEL ? > >> Also, should this be done first in jdk8 and then back-ported? > > Yes, absolutely. I forgot about that part. I believe JDK 8 is successfully > building on OS X and has everything from 7u6 so it shouldn't be that bad. > > -- Scott K. > >
