[NEW BUG]: Configure broken on MIPS

[Magnus Ihse Bursie]

On 2018-03-24 01:00, David Holmes wrote:
> On 24/03/2018 1:58 AM, Magnus Ihse Bursie wrote:
>>
>> On 2018-03-23 11:05, David Holmes wrote:
>>> On 23/03/2018 7:54 PM, Magnus Ihse Bursie wrote:
>>>>
>>>> On 2018-03-23 09:55, David Holmes wrote:
>>>>> On 23/03/2018 6:46 PM, Magnus Ihse Bursie wrote:
>>>>>>
>>>>>> On 2018-03-23 06:22, David Holmes wrote:
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> On 23/03/2018 2:55 PM, Thomas Stüfe wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> would it not be pragmatic to accept Ao's patch - it looks fine 
>>>>>>>> to me - since it certainly would not make matters worse. And 
>>>>>>>> let Magnus follow up with a cleanup change later?
>>>>>>>
>>>>>>> Well I hope Magnus's change is forthcoming. 
>>>>>> It might be some time still. I'm working on a complete overhaul 
>>>>>> of all CFLAGS and LDFLAGS, where this is a part of that picture, 
>>>>>> but I was not planning on addressing just this thing urgently.
>>>>>>
>>>>>> So, I think this patch will do for now. It solves the immediate 
>>>>>> problem for MIPS, and I can come back and make a cleaner solution 
>>>>>> later on.
>>>>>
>>>>> Isn't the best quick fix one that only adds -m64 for x86? I recall 
>>>>> a report that arm32 is similarly broken.
>>>> Not really, because this is also needed on some other platforms, at 
>>>> least s390x, as I recall. (This was the reason it was originally 
>>>> added.)
>>>
>>> According to gcc docs there are 4 archs that use m64 and we only 
>>> care about 2 of them:
>>>
>>> m64: SPARC Options
>>> m64: S/390 and zSeries Options
>>> m64: RS/6000 and PowerPC Options
>>> m64: i386 and x86-64 Options
>>>
>> Note that this logic also applies to the xlc compiler, not only gcc. 
>> I also believe that solstudio requires it on sparcv9, but I'm not 
>> 100% sure.
>>
>>> But you need to know whether you are dealing with S390 or S390x as 
>>> m64 implies zSeries.
>> We only support s390x (64-bit), not s390.
>>
>> And OpenJDK still support ppc64, even if Oracle does not test it. So 
>> I'd say that we need -m64 on all those platforms listed. So then the 
>> question is, is it easier to check if it's one of four, or not one of 
>> tree known CPU architectures. (For mips, we shouldn't test 
>> OPENJDK_TARGET_CPU for a lot of mips*, but OPENJDK_TARGET_CPU_ARCH 
>> for mips). For me, it's like, whatever. I'll probably rewrite this 
>> from the ground up anywhat. What we're trying to express here is that 
>> some flags are needed as CFLAGS always, even when running configure 
>> checks. It has really nothing to do with the number of CPU bits.
>
> My recollection for x86 was we only needed to specify -m64 to ensure a 
> 64-bit build if the compiler was not configured to do that by default. 
> Very much tied to the number of CPU bits we wanted to build for.
>
> In any case isn't the whole point of configure that you can check if a 
> compiler has a flag before you use it ??

Good point, the correct long term fix is probably to just check if 
-m<bits> is a supported option, instead of hardcoding platforms. I'll 
make a mental note of it.

/Magnus

>
> David
>
>> /Magnus
>>
>>>
>>> Ao will need a sponsor to create a bug etc regardless of which way 
>>> this goes.
>>>
>>> My week is over. :)
>>>
>>> Cheers,
>>> David
>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>> AFAICS it's as easy to write this only for x86 as it is to 
>>>>>>> exclude it for non x86. Honestly I don't know why the Aarch64 
>>>>>>> patch was done the way it was - there must be some subtlety here 
>>>>>>> that I'm not aware of.
>>>>>> I think it was just the smallest patch that worked for the 
>>>>>> aarch64 platform. I didn't spend time arguing about the fix, 
>>>>>> since it is supposed to be short-lived anyway.
>>>>>>
>>>>>> /Magnus
>>>>
>>