[aarch64-port-dev ] RFR: Fixes for native builds

[Andrew Dinn]

Hi Ed,

On 25/07/13 13:08, Edward Nevill wrote:
> On Thu, 2013-07-25 at 12:50 +0100, Andrew Dinn wrote:
>>> +      arm*)
>>> +        ZERO_ARCHFLAG=""
>>> +        ;;
>>>        aarch64)
>>>          ZERO_ARCHFLAG=""
>>>          ;;
>>
>>
>> Why is it necessary to add a case for arm* -- what has this to do
>> with how aarch64 works?
> 
> Yes. This is for arm 32 bit. I am also doing work on 32 bit and am
> using the same tree. So it is a convenience for me to add it. But no
> issue if you would prefer not to have it here.

Well, I guess this is ok if we remember why we added it. I don't want us
to be wondering about why it is there when we get to pushing the AArch64
changes upstream into JDK8. Is this also needed upstream? If so then
there is no problem having it in our tree but we probably ought to try
to push it in upstream now.

>>>      $(GENSRC_X11WRAPPERS_TMP)/sizer.%.exe : $(GENSRC_X11WRAPPERS_TMP)/sizer.%.c
>>>  	$(MKDIR) -p $(@D)
>>> -	(cd $(@D) && $(CC) -m$* -o $@ $< \
>>> +	(cd $(@D) && $(CC) -o $@ $< \
>>>                $(X_CFLAGS) \
>>>                $(X_LIBS) \
>>>                -I$(JDK_OUTPUTDIR)/include \
>>
>>
>> Why is there a need to remove the -m option? (what was the point of
>> having it in the first place? :-)
> 
> Because the ARM compilers (32 bit or 64 bit) do not have a -m option.
> On ARM you use a completely different compiler for 32/64 bit so your
> 64 bit compiler is always 64 bit and therefore doesn't have a -m64
> option. I have asked the gcc team to add a redundant -m64 option to
> the compiler just to save this sort of hassle but my request was
> laughed at.
> 
> As to why it was there in the first place. I don't know. It seems to
> be simply building some native code which it then execute to work out
> some offsets, so I don't believe it is necessary.
> 
> However, it needs to be fixed upstream anyway, since it is broken for
> ARM 32 and any other compilers that don't have the -m option. So by
> the time we get to merge this back into the trunk it will be fixed in
> some way. In the meantime, we dont care since the targets we care
> about dont have -m.

Ok, so this is the same as above -- we need it in our repo now but also
probably ought to push it upstream now.

regards,


Andrew Dinn
-----------