mirror of
https://github.com/openssl/openssl.git
synced 2024-12-09 05:51:54 +08:00
04b08fbc3d
Some last lflags to convert to ex_libs or a combo of lflags and ex_libs Reviewed-by: Rich Salz <rsalz@openssl.org> |
||
---|---|---|
.. | ||
00-base-templates.conf | ||
10-main.conf | ||
90-team.conf | ||
99-personal-ben.conf | ||
99-personal-bodo.conf | ||
99-personal-geoff.conf | ||
99-personal-levitte.conf | ||
99-personal-rse.conf | ||
99-personal-steve.conf | ||
README |
Configurations of OpenSSL target platforms ------------------------------------------ Target configurations are a collection of facts that we know about different platforms and their capabilities. We organise them in a hash table, where each entry represent a specific target. In each table entry, the following keys are significant: inherit_from => Other targets to inherit values from. Explained further below. [1] template => Set to 1 if this isn't really a platform target. Instead, this target is a template upon which other targets can be built. Explained further below. [1] sys_id => System identity for systems where that is difficult to determine automatically. cc => The compiler command, usually one of "cc", "gcc" or "clang". This command is normally also used to link object files and libraries into the final program. cflags => Flags that are used at all times when compiling. debug_cflags => Extra compilation flags used when making a debug build (when Configure receives the --debug option). Typically something like "-g -O0". release_cflags => Extra compilation flags used when making a release build (when Configure receives the --release option, or doesn't receive the --debug option). Typically something like "-O" or "-O3". thread_cflags => Extra compilation flags used when compiling with threading enabled. Explained further below. [2] shared_cflag => Extra compilation flags used when compiling for shared libraries, typically something like "-fPIC". ld => the linker command, usually not defined (meaning the compiler command is used instead). (NOTE: this is here for future use, it's not implemented yet) lflags => the flags that are used at all times when linking. These can have a % sign in them showing where the OpenSSL libraries should appear, otherwise these flags will come last. So in a typical links situation, this is a quick table of results: "-foo%-bar" > -foo -lssl -lcrypto -bar "-foo%" > -foo -lssl -lcrypto "-foo" > -lssl -lcrypto -foo debug_lflags => Like debug_cflags, but used when linking. release_lflags => Like release_cflags, but used when linking. shared_lflags => Like shared_cflags, but used when linking. ar => The library archive command, the default is "ar". (NOTE: this is here for future use, it's not implemented yet) arflags => Flags to be used with the library archive command. ranlib => The library archive indexing command, the default is 'ranlib' it it exists. unistd => An alternative header to the typical '<unistd.h>'. This is very rarely needed. shared_extension => File name extension used for shared libraries. obj_extension => File name extension used for object files. On unix, this defaults to ".o" (NOTE: this is here for future use, it's not implemented yet) exe_extension => File name extension used for executable files. On unix, this defaults to "" (NOTE: this is here for future use, it's not implemented yet) dso_scheme => The type of dynamic shared objects to build for. This mostly comes into play with engines, but can be used for other purposes as well. Valid values are "DLFCN" (dlopen() et al), "DLFCN_NO_H" (for systems that use dlopen() et al but do not have fcntl.h), "DL" (shl_load() et al), "WIN32" and "VMS". perlasm_scheme => The perlasm method used to created the assembler files used when compiling with assembler implementations. shared_target => The shared library building method used. This is a target found in Makefile.shared. build_scheme => The scheme used to build up a Makefile. In its simplest form, the value is a string with the name of the build scheme. The value may also take the form of a list of strings, if the build_scheme is to have some options. In this case, the first string in the list is the name of the build scheme. Currently recognised build schemes are "mk1mf" and "unixmake". Others may appear in the future. multilib => On systems that support having multiple implementations of a library (typically a 32-bit and a 64-bit variant), this is used 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 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. EXPORT_VAR_AS_FN for shared libraries, export vars as accessor functions. cpuid_obj => assembler implementation of cpuid code as well as OPENSSL_cleanse(). Default to mem_clr.o bn_obj => assembler implementation of core bignum functions. Defaults to bn_asm.o ec_obj => assembler implementation of core EC functions. des_obj => assembler implementation of core DES encryption functions. Defaults to 'des_enc.o fcrypt_b.o' aes_obj => assembler implementation of core AES functions. Defaults to 'aes_core.o aes_cbc.o' bf_obj => assembler implementation of core BF functions. Defaults to 'bf_enc.o' md5_obj => assembler implementation of core MD5 functions. sha1_obj => assembler implementation of core SHA1, functions, and also possibly SHA256 and SHA512 ones. cast_obj => assembler implementation of core BF functions. Defaults to 'c_enc.o' rc4_obj => assembler implementation of core BF functions. Defaults to 'rc4_enc.o rc4_skey.o' rmd160_obj => assembler implementation of core RMD160 functions. rc5_obj => assembler implementation of core RC4 functions. Defaults to 'rc5_enc.o' wp_obj => assembler implementation of core WHIRLPOOL functions. cmll_obj => assembler implementation of core CAMELLIA functions. Defaults to 'camellia.o cmll_misc.o cmll_cbc.o' modes_obj => assembler implementation of the functions gcm_gmult_4bit and gcm_ghash_4bit. padlock_obj => assembler implementation of core parts of the padlock engine. This is mandatory on any platform where the padlock engine might actually be built. [1] as part of the target configuration, one can have a key called 'inherit_from' that indicate what other configurations to inherit data from. These are resolved recursively. Inheritance works as a set of default values that can be overriden by corresponding key values in the inheriting configuration. Note 1: any configuration table can be used as a template. Note 2: pure templates have the attribute 'template => 1' and cannot be used as build targets. If several configurations are given in the 'inherit_from' array, the values of same attribute are concatenated with space separation. With this, it's possible to have several smaller templates for different configuration aspects that can be combined into a complete configuration. instead of a scalar value or an array, a value can be a code block of the form 'sub { /* your code here */ }'. This code block will be called with the list of inherited values for that key as arguments. In fact, the concatenation of strings is really done by using 'sub { join(" ",@_) }' on the list of inherited values. An example: "foo" => { template => 1, haha => "ha ha", hoho => "ho", ignored => "This should not appear in the end result", }, "bar" => { template => 1, haha => "ah", hoho => "haho", hehe => "hehe" }, "laughter" => { inherit_from => [ "foo", "bar" ], hehe => sub { join(" ",(@_,"!!!")) }, ignored => "", } The entry for "laughter" will become as follows after processing: "laughter" => { haha => "ha ha ah", hoho => "ho haho", hehe => "hehe !!!", ignored => "" } [2] OpenSSL is built with threading capabilities unless the user specifies 'no-threads'. The value of the key 'thread_cflags' may be "(unknown)", in which case the user MUST give some compilation flags to Configure. Historically, the target configurations came in form of a string with values separated by colons. This use is deprecated. The string form looked like this: "target" => "{cc}:{cflags}:{unistd}:{thread_cflag}:{sys_id}:{lflags}:{bn_ops}:{cpuid_obj}:{bn_obj}:{ec_obj}:{des_obj}:{aes_obj}:{bf_obj}:{md5_obj}:{sha1_obj}:{cast_obj}:{rc4_obj}:{rmd160_obj}:{rc5_obj}:{wp_obj}:{cmll_obj}:{modes_obj}:{padlock_obj}:{perlasm_scheme}:{dso_scheme}:{shared_target}:{shared_cflag}:{shared_ldflag}:{shared_extension}:{ranlib}:{arflags}:{multilib}"