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
