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

[Magnus Ihse Bursie]

On 2015-10-22 02:28, Martin Buchholz wrote:
> I agree that configure should try to invoke "the compiler" without any
> flags by default, but make it easy for users to supply them.  If some
> platform like SLES 10 on Linux/ppc64 wants to build 32-bit binaries, assume
> that this is intended and let it go ahead!  Don't just assume the distro
> maintainers are wrong.  I have some sympathy for the idea that "32-bit
> ought to be enough for everybody", and if it's not, switch to 64-bit then.
> The main reason to build everything 64-bit is simple avoidance of confusion
> and replication of runtime environments.

The problem here is that we can't just compile the native libraries as 
32 bits, without the rest of the build (java, hotspot etc) knowing about 
it. That's why configure takes this stance, "tell me if you want 32 or 
64 bits, and I'll fix it for you" (and the default being the same number 
of bits as the build platform).

If we really wanted to follow through on that idea, we'd have to query 
the compiler to see what it thinks is default. But I'm not sure that 
really makes sense, letting whatever the distro maintainer thought gcc 
should provide as default be what dictates whether we create a JVM 
that's 32 or 64 bit.

It might make sense, though, to not push a -m32/-m64 on all compile 
lines if it's not needed. But then we'd have to verify at configure time 
what kind of output the compiler produces as default, and add this flag 
according to if it behaves as expected or not.

/Magnus