sys_id => System identity for systems where that
is difficult to determine automatically.
+ enable => Enable specific configuration features.
+ This MUST be an array of words.
+ disable => Disable specific configuration features.
+ This MUST be an array of words.
+ Note: if the same feature is both enabled
+ and disabled, disable wins.
+
cc => The C compiler command, usually one of "cc",
"gcc" or "clang". This command is normally
also used to link object files and
files. On unix, this defaults to "" (NOTE:
this is here for future use, it's not
implemented yet)
+ shlib_variant => A "variant" identifier inserted between the base
+ shared library name and the extension. On "unixy"
+ platforms (BSD, Linux, Solaris, MacOS/X, ...) this
+ supports installation of custom OpenSSL libraries
+ that don't conflict with other builds of OpenSSL
+ installed on the system. The variant identifier
+ becomes part of the SONAME of the library and also
+ any symbol versions (symbol versions are not used or
+ needed with MacOS/X). For example, on a system
+ where a default build would normally create the SSL
+ shared library as 'libssl.so -> libssl.so.1.1' with
+ the value of the symlink as the SONAME, a target
+ definition that sets 'shlib_variant => "-abc"' will
+ create 'libssl.so -> libssl-abc.so.1.1', again with
+ an SONAME equal to the value of the symlink. The
+ symbol versions associated with the variant library
+ would then be 'OPENSSL_ABC_<version>' rather than
+ the default 'OPENSSL_<version>'. The string inserted
+ into symbol versions is obtained by mapping all
+ letters in the "variant" identifier to upper case
+ and all non-alphanumeric characters to '_'.
thread_scheme => The type of threads is used on the
configured platform. Currently known
to have the different variants in different
directories.
- bn_ops => Building options (was just bignum options
- in the earlier history of this option,
- hence the name). This a string of words
- that describe properties on the designated
- target platform, such as the type of
- integers used to build up the bitnum,
- different ways to implement certain ciphers
- and so on. To fully comprehend the
+ bn_ops => Building options (was just bignum options in
+ the earlier history of this option, hence the
+ name). This is a string of words that describe
+ algorithms' implementation parameters that
+ are optimal for the designated target platform,
+ such as the type of integers used to build up
+ the bignum, different ways to implement certain
+ ciphers and so on. To fully comprehend the
meaning, the best is to read the affected
source.
The valid words are:
- BN_LLONG use 'unsigned long long' in
- some bignum calculations.
- This has no value when
- SIXTY_FOUR_BIT or
- SIXTY_FOUR_BIT_LONG is given.
- RC4_CHAR makes the basic RC4 unit of
- calculation an unsigned char.
- SIXTY_FOUR_BIT processor registers
- are 64 bits, long is
- 32 bits, long long is
- 64 bits.
- SIXTY_FOUR_BIT_LONG processor registers
- are 64 bits, long is
- 64 bits.
- THIRTY_TWO_BIT processor registers
- are 32 bits.
+ THIRTY_TWO_BIT bignum limbs are 32 bits,
+ this is default if no
+ option is specified, it
+ works on any supported
+ system [unless "wider"
+ limb size is implied in
+ assembly code];
+ BN_LLONG bignum limbs are 32 bits,
+ but 64-bit 'unsigned long
+ long' is used internally
+ in calculations;
+ SIXTY_FOUR_BIT_LONG bignum limbs are 64 bits
+ and sizeof(long) is 8;
+ SIXTY_FOUR_BIT bignums limbs are 64 bits,
+ but execution environment
+ is ILP32;
+ RC4_CHAR RC4 key schedule is made
+ up of 'unsigned char's;
+ RC4_INT RC4 key schedule is made
+ up of 'unsigned int's;
EXPORT_VAR_AS_FN for shared libraries,
export vars as
accessor functions.
to be located in the source tree while files given through DEPEND are
expected to be located in the build tree)
-It's also possible to depend on static libraries explicitely:
+It's also possible to depend on static libraries explicitly:
DEPEND[foo]=libsomething.a
DEPEND[libbar]=libsomethingelse.a