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.
