SUN_ARCH_ABI property not set or in release file for aarch64 builds

Thu Apr 6 16:03:11 UTC 2017

On 06/04/2017 13:25, Andrey Petushkov wrote:
> 
>> On 05 Apr 2017, at 21:39, Simon Nash <simon at cjnash.com 
>> <mailto:simon at cjnash.com>> wrote:
>>
>> On 05/04/2017 15:50, Andrey Petushkov wrote:
>>>> On 05 Apr 2017, at 17:31, Simon Nash <simon at cjnash.com 
>>>> <mailto:simon at cjnash.com>> wrote:
>>>>
>>>> On 05/04/2017 14:43, Andrey Petushkov wrote:
>>>>> Dear Simon,
>>>>> Sorry for the delay. I was trying to build the code so that it has 
>>>>> the property, but apparently the necessary piece of magic is 
>>>>> missing. The location for that piece is only present in the 
>>>>> Oracle’s arm port repos, not anywhere else, including stock OpenJDK 
>>>>> 8u and 9. I doubt we want to integrate it just because of this 
>>>>> property. So we will think how to play around it..
>>>> Thanks for this information.  This is turning out to be more difficult
>>>> than I expected.
>>> The instructions from Bob should not be hard to follow. Although I’m 
>>> not quite sure the —with-extra-cflags is the best implementation it 
>>> should be good for you
>>
>> Are you suggesting that I should create and test a patch for 8u based on
>> Bob's instructions and submit it for merging into the 8u codebase?
> No, not in any way. And indeed, Bob’s instructions for 8u cannot make 
> any patch since they are for the entity which runs configure script. 
> Which is user. Which is not a part of the repos :)

Thanks, I see now that the #ifdefs that Bob mentioned are present in the
jdk8u sources but in different files.  I will give this a try.

>>
>>>>>> 03 Apr 2017, at 23:57, Simon Nash <simon at cjnash.com 
>>>>>> <mailto:simon at cjnash.com>> wrote:
>>>>>>
>>>>>> Hi Andrey,
>>>>>> I am using the OpenJDK sources in the aarch32-port repository to build
>>>>>> a JRE for my application, so it will help to have this property set by
>>>>>> this JRE.  I will try my current binary to see whether this property
>>>>>> is already available.
>>>>> If you’re building from Oracle’s port I believe Bob should be able 
>>>>> to tell how to bring the magic over. Otherwise please stay tuned, 
>>>>> we’ll work on bringing it into the rest of aarch32 repos
>>>> For JDK 8, I am building aarch32-port/jdk8u.  For JDK 9, I was building
>>>> aarch32-port/arm-3264.  Since this has been merged into jdk9/jdk9 I am
>>>> now building jdk9/jdk9 instead.
>>>>
>>>>>> I have sucessfully built the aarch32-port sources for gnueabihf but I
>>>>>> could not build them for gnueabi becaise there appear to be some 
>>>>>> missing
>>>>>> files in the aarch32-port sources that are neeeded for softfp support.
>>>>>> Is this correct?  If so, are there any plans to support a softfp 
>>>>>> version?
>>>>> Could you please indicate what repos are you building from: 8u, 9 
>>>>> or 9-arm3264 (aka Oracle)
>>>> See above.  I have got softfp working with 9-arm3264 but I wasn't able
>>>> to build 8u with softfp because of missing files.
>>> What files are you missing? Could you please elaborate a bit?
>>
>> I will go back and recheck on the details and post here when I have them.
>>
>>> One more question, is softfp is mandatory for you? The reason why I’m 
>>> asking is that we’re regularly building 8u in soft-float 
>>> configuration with VFP support in hotspot compiler. It should give 
>>> almost the same performance as softfp. As what to softfp itself it 
>>> might be broken, we’re not testing it
>>
>> I would like to run 8u on ARMv5 machines that only support gnueabi and
>> don't have hardware floating-point support.  I have built a JDK9 runtime
>> for this from the 9-arm3264 sources and I have verified that it works.
> A-ha, then the problem should be not in VP but rather in ARMv5. Sorry to 
> say but aarch32-8u codebase does not support any ARM core lower than 
> v6k. (Although it should be pretty easy to make interpreter work on v5 
> and even below)
> 

Thanks for the clarification.

Simon

> Andrey
>>
>> Simon
>>
>>> Thanks,
>>> Andrey
>>>> Simon
>>>>
>>>>> Thanks,
>>>>> Andrey
>>>>>> Best regards,
>>>>>> Simon
>>>>>>
>>>>>> On 03/04/2017 21:45, Andrey Petushkov wrote:
>>>>>>> Hi Simon,
>>>>>>> from the first glance it's set with the command line when the 
>>>>>>> binary is built.  so there is no code change is required but 
>>>>>>> rather build system setup.  we can ensure Azul is building with 
>>>>>>> it so it will propagate into any downstream distribution taking 
>>>>>>> our binaries. yet it might help you or might not depending on 
>>>>>>> what you call the "openjdk build"
>>>>>>> Regards,
>>>>>>> Andrey
>>>>>>> On Mon, Apr 3, 2017, 23:18 Simon Nash <simon at cjnash.com 
>>>>>>> <mailto:simon at cjnash.com> <mailto:simon at cjnash.com>> wrote:
>>>>>>>  On 03/04/2017 17:58, Bob Vandette wrote:
>>>>>>>   > The Oracle binaries for JDK 8 and JDK 9 Linux arm already include
>>>>>>>  this property for the
>>>>>>>   > 32-bit ARM binaries.
>>>>>>>   >
>>>>>>>   > The only release that in question is the 64-bit aarch64 Linux
>>>>>>>  distribution.  There’s really
>>>>>>>   > no need for this property since there’s only 1 ABI that’s widely
>>>>>>>  used today on that
>>>>>>>   > architecture.
>>>>>>>   >
>>>>>>>   > Bob.
>>>>>>>   >
>>>>>>>  My comment was about the OpenJDK aarch32 builds.  From your original
>>>>>>>  post,
>>>>>>>  I have the impression that the OpenJDK aarch32 builds don't set this
>>>>>>>  property.
>>>>>>>  If it could be added for the OpenJDK aarch32 builds, this would be
>>>>>>>  very useful
>>>>>>>  for my application.
>>>>>>>  I understand that this is not needed for aarch64 builds.
>>>>>>>  Simon
>>>>>>>   >> On Apr 3, 2017, at 12:53 PM, Simon Nash <simon at cjnash.com 
>>>>>>> <mailto:simon at cjnash.com>
>>>>>>>  <mailto:simon at cjnash.com>> wrote:
>>>>>>>   >>
>>>>>>>   >> Hi Bob,
>>>>>>>   >> I would find such a property very useful.
>>>>>>>   >>
>>>>>>>   >> My application is mostly written in Java but also uses a native
>>>>>>>  library
>>>>>>>   >> that is loaded dynamically by the Java code.  In order to 
>>>>>>> distribute
>>>>>>>   >> fewer versions of the application and make things simpler 
>>>>>>> for users,
>>>>>>>   >> I have recently started packaging multiple versions of the
>>>>>>>  native library
>>>>>>>   >> (for example, Intel x86 and Intel x64) in a single version 
>>>>>>> of the
>>>>>>>   >> application and using Java runtime properties to determine 
>>>>>>> which of
>>>>>>>   >> these native libraries to load.
>>>>>>>   >>
>>>>>>>   >> I would like to do this for gnueabi and gnueabihf if I could 
>>>>>>> find a
>>>>>>>   >> reliable way to determine at runtime which of these native 
>>>>>>> libraries
>>>>>>>   >> is needed.  It sounds like this property would be an ideal 
>>>>>>> solution.
>>>>>>>   >>
>>>>>>>   >> Best regards,
>>>>>>>   >> Simon
>>>>>>>   >>
>>>>>>>   >> On 03/04/2017 16:57, Bob Vandette wrote:
>>>>>>>   >>> I’m inclined to not fix this bug but thought I’d bring it to
>>>>>>>  your attention just in case.
>>>>>>>   >>> I assume that OpenJDK ARM builds never set this property
>>>>>>>  anyway, right?
>>>>>>>   >>> https://bugs.openjdk.java.net/browse/JDK-8177976
>>>>>>>  <https://bugs.openjdk.java.net/browse/JDK-8177976>
>>>>>>>   >>> Bob.
>>>>>>>   >
>>>>>>>   >
> 