> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Bill Hallahan > Sent: Wednesday, June 26, 2019 16:29 > I am trying to build openssl-1.1.1-c on AIX using the xlc compiler. > I have found the c99 compiler and the xlc compiler seem to work best. The arguments > produced by the following configuration command are not compatible with gcc. > ./config -static no-ec no-mdc2 no-rc5 no-idea --openssldir=/path_sanitized We run Configure rather than config, bootstrapping our AIX openssl build with: $ ./Configure aix-cc threads enable-ssl3 no-ec2m no-idea no-rc5 enable-weak-ssl-ciphers no-shared -DOPENSSL_NO_AUTOLOAD_CONFIG --prefix=`pwd`/buildoutput --openssldir=`pwd`/buildoutput -qmaxmem=-1 -qlanglvl-stdc99 -qlanglvl=stdc99 -D_LARGE_FILES=1 (I'm not currently the maintainer of our OpenSSL build process, so I can't provide the rationale for all of that, but it's working in our environment.) For 64-bit, use aix64-cc instead. Now, that's what config ought to select, but I'm not a fan of config, personnally. For a repeatable build process I like to tell the OpenSSL build process how to configure itself. > I would prefer to use the xlc compiler. The "c99" and "xlc" commands both invoke the same compiler - IBM's XL C compiler (aka "C/Set", etc, in some releases). They just set different default options for things like language level and extensions. > (I am still trying to figure out how to get the compiler version. "-V" does not work). $ lslpp -i '*xlc*' will list the LPPs (Licensed Program Products) that have "xlc" in the name. You should have one named xlccmp.X.Y.Z, followed by a handful with the same name variously suffixed (e.g. "xlccmp.13.1.0.lib"). The X.Y.Z are the XLC version. For more info, run e.g. $ lslpp -l xlccmp.13.1.0 which will show what patch level you're at. The LPP stuff is one of the remaining AIXisms in AIX. > I was getting many linker errors, but I have fixed the Makefile to include certain > libraries. That shouldn't be necessary, so it sounds like configuration did not run properly. > Now I just have one unresolved external, which is "ecp_nistz256_mul_mont". Well, that does sound like an issue with the assembly routines, since there's a PPC version of that one (I think, glancing at the source). You could try configurinng with no-asm, but generally you only want to do that when diagnosing an issue, not for production use. (There's widespread opinion that OpenSSL is too slow for production use without the assembly routines. I think that depends on use cases, but it's a popular opinion.) > I've tried adding -DECP_NISTZ256_ASM to the compile lines, but I still get that > unresolved external. Trying to fool the configuration generally isn't a useful approach. I suggest reconfiguring, using a variation on my command line above that includes the options you want. Or you might try mine verbatim (well, probably without --prefix and --openssldir) to see if it works, then change it to use your options to see if you can narrow down what's causing the issue. Incidentally: why no-ec? Removing all ECC is going to give you a rather outdated set of crypto algorithms. If you're concerned about possible IP encumbrance, I'd recommend no-ec2m. (I am not a lawyer, but I'm happy to offer worthless legal advice on the Internet.) -- Michael Wojcik Distinguished Engineer, Micro Focus
