hardcoding -m32/-m64 is more harmful than using the toolchain defaults

[Magnus Ihse Bursie]

On 2015-10-20 14:14, Matthias Klose wrote:
> On 20.10.2015 09:36, David Holmes wrote:
>>> On 20/10/2015 6:50 AM, Matthias Klose wrote:
>>>> I'm working around some build failures for zero targets, which fail to
>>>> build because the configury in openjdk tries to set -m32/-m64 on it's
>>>> own.  I assume this behaviour was added for sun/oracle product 
>>>> builds to
>>>> build x86 and x86_64 targets on a x86_64 platform.  The issue is that
>>>> the current configury checks if -m32/-m64 works with the current
>>>> compiler, and then enables it without losses. This breaks at least on
>>>> the x86_64-linux-gnux32 target. 
What does x86_64-linux-gnux32 imply? Some sort of mix between 32 and 64-bit?

>>>> I assume it will break on other targets
>>>> as well, which don't recognize -m32/-m64, but usually use other 
>>>> options
>>>> like -mabi=<name>.  Instead of hard-coding these flags for every
>>>> architecture, is there any chance for not passing these flags at 
>>>> all for
>>>> the default mode?
>>
>> Part of the problem is that the default mode is not known ahead of 
>> time, your
>> gcc on your x64 system might be configured to build 32-bit by default.
>
> is this really a common configuration?  I don't know any Linux 
> distribution shipping such a compiler.  The one possibility for a 
> 32bit toolchain on a 64bit host might be a x86 chroot created on a 
> x86_64 host.  But usually such build environments are entered with a 
> 32bit personality (see linux32(1)), hiding anything build related from 
> the host.

Originally we started adding -m32 to force 32-bit builds on 64-bit 
platforms. I think the wide usage of -m64 more arouse as a symmetrical 
counterpart, rather than a conscious design decision. I do not think the 
current implementation is optimal, but it has worked for us. :-)

> I would expect that the default mode is passed in some way as autoconf 
> option, or by setting CC="gcc -m64" (the latter unfortunately not 
> working because CC is expected to be a file name in some places).
Setting CC="compiler -arg" have worked in the past. The intention is 
that it should work. But since it's not regularly tested, it has 
probably broken somewhere. Thanks for pointing it out.

>
>> If there is a better way to select this than -m32/-m64 then I'm happy 
>> to hear
>> it, but not sure if -march/-mabi gives us anything better on x86. 
>> What exactly
>> would you propose?
>
> I'm not proposing to use -march/-mabi instead, but just avoiding 
> -m32/-m64 at all, unless you explicitly configure for it (e.g. 
> --with-abi=<abi-option> ?).

Overall, our handling of compiler flags is quite a mess. Erik and I have 
talked on multiple occasions to rewrite this. Our basic idea was that we 
should split down the flag definitions into more manageble chunks, that 
can be selectivly appended to the compilation line. For this case, you 
could imagine e.g. JDK_ARCH_CFLAGS or JDK_ABI_CFLAGS, which could be set 
to -m32, -m64 or nothing at all, depending on use case.

/Magnus