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

David Holmes david.holmes at oracle.com
Wed Oct 21 02:03:59 UTC 2015


On 20/10/2015 10:14 PM, 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.  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).

The default is to assume you want a build that matches the architecture 
of the build platform. Configure options can change that - eg 
--with-target-bits=32 request a 32-bit build on a 64-bit system. That in 
turn should cause the correct flags to be passed to the compiler to get 
the desired result. If -m32/-m64 are not the right flags for a given 
compiler then we may have to look at that, but we have a set of 
supported compilers and can't try to handle every possibility.

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

That may be possible.

David


> Matthias
>



More information about the build-dev mailing list