1 Configurations of OpenSSL target platforms
2 ------------------------------------------
4 Target configurations are a collection of facts that we know about
5 different platforms and their capabilities. We organise them in a
6 hash table, where each entry represent a specific target.
8 In each table entry, the following keys are significant:
10 inherit_from => Other targets to inherit values from.
11 Explained further below. [1]
12 template => Set to 1 if this isn't really a platform
13 target. Instead, this target is a template
14 upon which other targets can be built.
15 Explained further below. [1]
17 sys_id => System identity for systems where that
18 is difficult to determine automatically.
20 cc => The compiler command, usually one of "cc",
21 "gcc" or "clang". This command is normally
22 also used to link object files and
23 libraries into the final program.
24 cflags => Flags that are used at all times when
26 debug_cflags => Extra compilation flags used when making a
27 debug build (when Configure receives the
28 --debug option). Typically something like
30 release_cflags => Extra compilation flags used when making a
31 release build (when Configure receives the
32 --release option, or doesn't receive the
33 --debug option). Typically something like
35 thread_cflags => Extra compilation flags used when
36 compiling with threading enabled.
37 Explained further below. [2]
38 shared_cflag => Extra compilation flags used when
39 compiling for shared libraries, typically
40 something like "-fPIC".
42 ld => the linker command, usually not defined
43 (meaning the compiler command is used
45 (NOTE: this is here for future use, it's
47 lflags => the flags that are used at all times when
48 linking. These can have a % sign in them
49 showing where the OpenSSL libraries should
50 appear, otherwise these flags will come
51 last. So in a typical links situation,
52 this is a quick table of results:
54 "-foo%-bar" > -foo -lssl -lcrypto -bar
55 "-foo%" > -foo -lssl -lcrypto
56 "-foo" > -lssl -lcrypto -foo
58 debug_lflags => Like debug_cflags, but used when linking.
59 release_lflags => Like release_cflags, but used when linking.
60 shared_lflags => Like shared_cflags, but used when linking.
62 ar => The library archive command, the default is
64 (NOTE: this is here for future use, it's
66 arflags => Flags to be used with the library archive
69 ranlib => The library archive indexing command, the
70 default is 'ranlib' it it exists.
72 unistd => An alternative header to the typical
73 '<unistd.h>'. This is very rarely needed.
75 shared_extension => File name extension used for shared
77 obj_extension => File name extension used for object files.
78 On unix, this defaults to ".o" (NOTE: this
79 is here for future use, it's not
81 exe_extension => File name extension used for executable
82 files. On unix, this defaults to "" (NOTE:
83 this is here for future use, it's not
86 dso_scheme => The type of dynamic shared objects to build
87 for. This mostly comes into play with
88 engines, but can be used for other purposes
89 as well. Valid values are "DLFCN"
90 (dlopen() et al), "DLFCN_NO_H" (for systems
91 that use dlopen() et al but do not have
92 fcntl.h), "DL" (shl_load() et al), "WIN32"
94 perlasm_scheme => The perlasm method used to created the
95 assembler files used when compiling with
96 assembler implementations.
97 shared_target => The shared library building method used.
98 This is a target found in Makefile.shared.
99 build_scheme => The scheme used to build up a Makefile.
100 In its simplest form, the value is a string
101 with the name of the build scheme.
102 The value may also take the form of a list
103 of strings, if the build_scheme is to have
104 some options. In this case, the first
105 string in the list is the name of the build
107 Currently recognised build schemes are
108 "mk1mf" and "unixmake". Others may appear
111 multilib => On systems that support having multiple
112 implementations of a library (typically a
113 32-bit and a 64-bit variant), this is used
114 to have the different variants in different
117 bn_ops => Building options (was just bignum options
118 in the earlier history of this option,
119 hence the name). This a string of words
120 that describe properties on the designated
121 target platform, such as the type of
122 integers used to build up the bitnum,
123 different ways to implement certain ciphers
124 and so on. To fully comprehend the
125 meaning, the best is to read the affected
129 DES_PTR use a pointer to DES_SPtrans
130 rather that DES_SPtrans
131 directly in D_ENCRYPT.
132 DES_RISC1 Alternate implementations of
133 DES_RISC2 D_ENCRYPT for certain RISC
135 DES_UNROLL do not loop around calls to
137 DES_INT have unsigned int as the
138 integer type for DES rather
140 BN_LLONG use 'unsigned long long' in
141 some bignum calculations.
142 This has no value when
144 SIXTY_FOUR_BIT_LONG is given.
145 RC4_CHAR makes the basic RC4 unif of
146 calculation an unsigned char.
147 RC4_LONG makes the basic RC4 unif of
148 calculation an unsigned long.
149 RC4_INDEX go through input and output
150 data by indexing into them
151 rather than incrementing the
153 RC4_CHUNK sets the chunk type to
155 RC4_CHUNK_LL sets the chunk type to
157 both these chunk sizes are for
158 handling data in chunks on
159 processors that do not have
160 byte load/store instructions.
161 MD2_CHAR makes the basic MD2 unit of
162 calculation an unsigned char.
163 MD2_LONG makes the basic MD2 unit of
164 calculation an unsigned long.
165 IDEA_SHORT makes the basic IDEA unit of
166 calculation an unsigned short.
167 IDEA_LONG makes the basic IDEA unit of
168 calculation an unsigned long.
169 RC2_SHORT makes the basic RC2 unit of
170 calculation an unsigned short.
171 RC2_LONG makes the basic RC2 unit of
172 calculation an unsigned long.
173 BF_PTR use different pointer based
174 BF_PTR2 versions of BF_ENC.
175 SIXTY_FOUR_BIT processor registers
177 32 bits, long long is
179 SIXTY_FOUR_BIT_LONG processor registers
182 THIRTY_TWO_BIT processor registers
184 EXPORT_VAR_AS_FN for shared libraries,
188 cpuid_obj => assembler implementation of cpuid code as
189 well as OPENSSL_cleanse().
191 bn_obj => assembler implementation of core bignum
194 ec_obj => assembler implementation of core EC
196 des_obj => assembler implementation of core DES
197 encryption functions.
198 Defaults to 'des_enc.o fcrypt_b.o'
199 aes_obj => assembler implementation of core AES
201 Defaults to 'aes_core.o aes_cbc.o'
202 bf_obj => assembler implementation of core BF
204 Defaults to 'bf_enc.o'
205 md5_obj => assembler implementation of core MD5
207 sha1_obj => assembler implementation of core SHA1,
208 functions, and also possibly SHA256 and
210 cast_obj => assembler implementation of core BF
212 Defaults to 'c_enc.o'
213 rc4_obj => assembler implementation of core BF
215 Defaults to 'rc4_enc.o rc4_skey.o'
216 rmd160_obj => assembler implementation of core RMD160
218 rc5_obj => assembler implementation of core RC4
220 Defaults to 'rc5_enc.o'
221 wp_obj => assembler implementation of core WHIRLPOOL
223 cmll_obj => assembler implementation of core CAMELLIA
225 Defaults to 'camellia.o cmll_misc.o cmll_cbc.o'
226 modes_obj => assembler implementation of the
227 functions gcm_gmult_4bit and gcm_ghash_4bit.
228 padlock_obj => assembler implementation of core parts of
229 the padlock engine. This is mandatory on
230 any platform where the padlock engine might
234 [1] as part of the target configuration, one can have a key called
235 'inherit_from' that indicate what other configurations to inherit
236 data from. These are resolved recursively.
238 Inheritance works as a set of default values that can be overriden
239 by corresponding key values in the inheriting configuration.
241 Note 1: any configuration table can be used as a template.
242 Note 2: pure templates have the attribute 'template => 1' and
243 cannot be used as build targets.
245 If several configurations are given in the 'inherit_from' array,
246 the values of same attribute are concatenated with space
247 separation. With this, it's possible to have several smaller
248 templates for different configuration aspects that can be combined
249 into a complete configuration.
251 instead of a scalar value or an array, a value can be a code block
252 of the form 'sub { /* your code here */ }'. This code block will
253 be called with the list of inherited values for that key as
254 arguments. In fact, the concatenation of strings is really done
255 by using 'sub { join(" ",@_) }' on the list of inherited values.
263 ignored => "This should not appear in the end result",
272 inherit_from => [ "foo", "bar" ],
273 hehe => sub { join(" ",(@_,"!!!")) },
277 The entry for "laughter" will become as follows after processing:
286 [2] OpenSSL is built with threading capabilities unless the user
287 specifies 'no-threads'. The value of the key 'thread_cflags' may
288 be "(unknown)", in which case the user MUST give some compilation
292 Historically, the target configurations came in form of a string with
293 values separated by colons. This use is deprecated. The string form
296 "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}"