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

[Matthias Klose]

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.  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.

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).

> 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> ?).

Matthias