Upgrade to openssl-1.0.2a (Part1)

[shigeki]

This is a resubmitted PR of #723. It still stays in 1.0.1m but requires the following 5 changes just before upgrading 1.0.2a.

• upgrade gyp to use else if conditions as supported in https://codereview.chromium.org/601353002
• refactor openssl.gyp so as to switch target_arch and OS with "else if" condition
• move sources, rules and defines into openssl.gypi, openssl-cli.gypi and masm_compile.gypi
• apply two private patches to fix gyp to run on MacOS without XCode and Fedor's fix for python2.6.
• add rsa and aes-gcm benchmarks and new hash algorithms in order to compare the performances after upgrade.

I confirmed there is no differences in out/deps/openssl/openssl.target.mk with this changes on several platforms.

CI shows that there are a few new errors on win2008r2 but they are not related to this change. Others are fine except known failures.
https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/430/

After this, I will submit the 2nd PR to finish upgrade to 1.0.2a in https://github.com/shigeki/io.js/tree/upgrade_openssl102a.
Preliminary results to show performance gains after upgrade are in https://gist.github.com/shigeki/eefc31f9d82f45f9a8e3 .

R= @bnoordhuis @indutny

[indutny]

Some nits otherwise LGTM. @bnoordhuis PTAL too.

[bnoordhuis]

Left some comments. Mostly LGTM though.

I'm not quite sure why it was necessary to split up openssl.gyp. Can you explain?

[shigeki]

@bnoordhuis @indutny Thanks for reviewing. I will fix them soon.
The reasons why I splited up openssl.gyp are that

• Sources and defines in openssl.gyp are getting so huge because of increase of supported architectures such as arms and two sets of asm files, one is for the latest avx2 supported compiler and the other is for the older.
• We can only focus and modify the changes of sources and defines of openssl.gypi in version up and less worries about platform dependent logics that are defined in openssl.gyp.
• It's easy to add a new supported architecture. For example, adding armv8 is as blow in openssl.gyp, where it's easy to debug and identify issues when they occur.

@@ -69,6 +69,9 @@
                 '<@(openssl_defines_x64_elf)',
               ],
               'sources': ['<@(openssl_sources_x64_elf_gas)'],
+            }, 'target_arch=="arm64"', {
+              'defines': ['<@(openssl_defines_arm64)',],
+              'sources': ['<@(openssl_sources_arm64_linux64_gas)'],
             }, { # else other archtectures does not use asm
               'defines': [
                 'OPENSSL_NO_ASM',

[shigeki]

Styles are fixed by checking with gjslint. Other fixes are made according comments and I replied them. The branch are force pushed.

@bnoordhuis Could you give me an another LGTM if you accept my explanations above?

[rvagg]

very exciting, I won't lgtm because this is out of my area but does this reenable openssl on armv8 as well? my understanding is that 1.0.2 should give us the support we need there.

[shigeki]

@rvagg The armv8 support with assembler codes has already been done in the forthcoming commits as shigeki@d133ae5 and shigeki@1cca321. Could you install automake and libtool on the armv8 host in Jenkins for libuv tests? After resolving the build failure of libuv in https://jenkins-iojs.nodesource.com/job/libuv+any-pr+multi/nodes=iojs-armv8-ubuntu1404/lastBuild/console, I can work spawnSync failures on armv8 with shigeki@5baf3dd .

[jbergstroem]

I'm very happy about the split tbh -- makes it so much more manageable.

[bnoordhuis]

LGTM

[rvagg]

@shigeki sorry, I think this is good to go now but the state of libuv tests on armv8 is apparently pretty tragic! https://jenkins-iojs.nodesource.com/job/libuv+any-pr+multi/74/nodes=iojs-armv8-ubuntu1404/console /cc @libuv/owners

[rvagg]

perhaps @libuv/owners isn't right here, anyway, cc @saghul

[bnoordhuis]

@rvagg If you can give me a login for the armv8 bot, I can look into it. I'm 95% sure I know what's wrong but I need some time with strace to confirm.

[indutny]

LGTM

[rvagg]

@bnoordhuis will have to do this later, it's behind a jump-host that's set up just with my creds so I'll probably need to make an ssh tunnel to let you in to it.

[Fishrock123]

@shigeki this doesn't look semver-minor though? It looks fine for a x.y.patch to me?

[shigeki]

@Fishrock123 Yes, it does not contain API changes. But I wonder it makes some confusion as this title is the first part of upgrading of the deps library. If you don't mind, I will merge this right now.

[Fishrock123]

@shigeki Well, the commits themselves are fairly self explanatory, maybe don't squash?

[shigeki]

@Fishrock123 No, I don't squash them. I will merge each ones separately.

[gibfahn]

For some reason e7c3f4a97b is showing on branch-diff for 6.x, not sure why as be65f5f is in the v6.x branch already.