Update configure

[shahidhs]

After running './configure' on s390x architecture VM, I was getting following output:

bash-4.3# uname -rvmpio
3.10.0-229.1.2.el7.s390x #1 SMP Fri Mar 6 17:14:40 EST 2015 s390x s390x s390x GNU/Linux

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
'default_configuration': 'Release',
'defines': [],
'include_dirs': [],
'libraries': []},
'variables': { 'clang': 0,
'gcc_version': 49,
'host_arch': 's390',
'node_byteorder': 'big',
'node_install_npm': 'true',
'node_prefix': '',
'node_shared_cares': 'false',
'node_shared_http_parser': 'false',
'node_shared_libuv': 'false',
'node_shared_openssl': 'false',
'node_shared_v8': 'false',
'node_shared_zlib': 'false',
'node_tag': '',
'node_unsafe_optimizations': 0,
'node_use_dtrace': 'false',
'node_use_etw': 'false',
'node_use_openssl': 'true',
'node_use_perfctr': 'false',
'node_use_systemtap': 'false',
'openssl_no_asm': 0,
'python': '/usr/bin/python',
'target_arch': 's390',
'v8_enable_gdbjit': 0,
'v8_no_strict_aliasing': 1,
'v8_use_snapshot': 'true',
'want_separate_host_toolset': 0}}
creating ./config.gypi
creating ./config.mk
bash-4.3#

As we could see, the configure script has returned me incorrect architecture i.e. 's390' instead of 's390x'. I got this behavior for Fedora21, RHEL7, SLES12 and MCP8 OS. This causes 'make' fail as it tries to build for 's390' instead on 's390x'.

I am proposing the mentioned changes for fixing the issue.

Below is the output when I run the updated './configure' script:

bash-4.3# ./configure
{ 'target_defaults': { 'cflags': [],
'default_configuration': 'Release',
'defines': [],
'include_dirs': [],
'libraries': []},
'variables': { 'clang': 0,
'gcc_version': 49,
'host_arch': 's390x',
'node_byteorder': 'big',
'node_install_npm': 'true',
'node_prefix': '',
'node_shared_cares': 'false',
'node_shared_http_parser': 'false',
'node_shared_libuv': 'false',
'node_shared_openssl': 'false',
'node_shared_v8': 'false',
'node_shared_zlib': 'false',
'node_tag': '',
'node_unsafe_optimizations': 0,
'node_use_dtrace': 'false',
'node_use_etw': 'false',
'node_use_openssl': 'true',
'node_use_perfctr': 'false',
'node_use_systemtap': 'false',
'openssl_no_asm': 0,
'python': '/usr/bin/python',
'target_arch': 's390x',
'v8_enable_gdbjit': 0,
'v8_no_strict_aliasing': 1,
'v8_use_snapshot': 'true',
'want_separate_host_toolset': 0}}
creating ./config.gypi
creating ./config.mk
bash-4.3#

Now it correctly identifies the host architecture for s390x.

Thanks.

[mhdawson]

Thanks for identifying this issue. Looking at the problem we think its probably better to change the ordering in matchup to be:

matchup = {
'x86_64' : 'x64',
'i386' : 'ia32',
'arm' : 'arm',
'mips' : 'mips',
'PPC64' : 'ppc64',
'PPC' : 'ppc',
'_ARCH_PPC' : 'ppc',
's390x' : 's390x',
's390' : 's390',
}

This is consistent with other platforms and we believe will result in the right behavior for both 32 and 64 bit.

If you validate that it resolves the problem for you we'll go ahead and make the change to the ordering.

Separately, to be able to accept pulls requests we'd need to get you to sign a Contributor Licence Agreement. Is that something you'd be interested in doing ?

[joransiu]

@mhdawson That was my initial reaction as well, but there is no ordering guarantee when accessing keys from a dictionary. With the python version I used, it happens that s390 will be accessed in the subsequent for-loop before s390x, even if s390x is listed first in the code.

[shahidhs]

@joransiu Yes you are right. Its still picking up 's390'.

As there are two match happening for system Z architecture, can we try following:
for i in matchup:
if i in k and k[i] != '0':
rtn = matchup[i]
if ((rtn == 's390') or (rtn == 's390x')):
continue;
else:
break;

The above will check the output of 'cc_macros' till end for system z and will use the last matched architecture. Worked for me. Any suggestions?

[joransiu]

Thanks @shahidhs. Yeah, your suggestion there will work until some python implementation decides to give s390x first before s390. Perhaps the best way is to just have "if ((rtn == 's390')) continue;". If you match the 64-bit s390x platform, you would want to break out of the loop with that. I do wonder if we want something a bit more generic than this, as other platforms may potentially have the same issue with their macros. I'll follow up again soon.

[shahidhs]

Thanks @joransiu
I have updated the file as per your suggestion.

[joransiu]

Thanks @shahidhs for contributing the fix.