[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    RE: Link error with openssl-1.1.1-c on AIX
From:       Michael Wojcik <Michael.Wojcik () microfocus ! com>
Date:       2019-06-26 23:16:07
Message-ID: BYAPR18MB2918EC342B45BF42AC03009EF9E20 () BYAPR18MB2918 ! namprd18 ! prod ! outlook ! com
[Download RAW message or body]

> From: openssl-users [mailto:openssl-users-bounces@openssl.org] 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


[prev in list] [next in list] [prev in thread] [next in thread]