Configurations of OpenSSL target platforms
==========================================
-Target configurations are a collection of facts that we know about
+Configuration targets 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.
+Note that configuration target names must be unique across all config
+files. The Configure script does check that a config file doesn't
+have config targets that shadow config targets from other files.
+
In each table entry, the following keys are significant:
inherit_from => Other targets to inherit values from.
Note: if the same feature is both enabled
and disabled, disable wins.
+ cpp => The C preprocessor command, normally not
+ given, as the build file defaults are
+ usually good enough.
+ cppflags => The C preprocessor flags.
+ defines => As an alternative, macro definitions may be
+ given here instead of in `cppflags'. If
+ given here, they MUST be as an array of the
+ string such as "MACRO=value", or just
+ "MACRO" for definitions without value.
+ includes => As an alternative, inclusion directories
+ may be given here instead of in `cppflags'.
+ If given here, the MUST be an array of
+ strings, one directory specification each.
cc => The C compiler command, usually one of "cc",
"gcc" or "clang". This command is normally
also used to link object files and
cxxflags => Flags that are used at all times when
compiling C++ object files. If unset, it
gets the same value as cflags.
- defines => As an alternative, macro definitions may be
- present here instead of in `cflags'. If
- given here, they MUST be as an array of the
- string such as "MACRO=value", or just
- "MACRO" for definitions without value.
shared_cflag => Extra compilation flags used when
compiling for shared libraries, typically
something like "-fPIC".
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
export vars as
accessor functions.
- apps_extra_src => Extra source to build apps/openssl, as
- needed by the target.
+ apps_aux_src => Extra source to build apps/openssl and other
+ apps, as needed by the target and that can be
+ collected in a library.
+ apps_init_src => Init source to build apps/openssl and other
+ apps, as needed by the target. This code
+ cannot be placed in a library, as the rest
+ of the code isn't expected to link to it
+ explicitely.
cpuid_asm_src => assembler implementation of cpuid code as
well as OPENSSL_cleanse().
Default to mem_clr.c
static libraries on Windows can only be done when configured
'no-shared'.
-For some libraries, we maintain files with public symbols and their
-slot in a transfer vector (important on some platforms). It can be
-declared like this:
-
- ORDINALS[libcrypto]=crypto
-
-The value is not the name of the file in question, but rather the
-argument to util/mkdef.pl that indicates which file to use.
-
One some platforms, shared libraries come with a name that's different
from their static counterpart. That's declared as follows:
GENERATE[bar.s]=asm/bar.S
The value of each GENERATE line is a command line or part of it.
-Configure places no rules on the command line, except the the first
-item muct be the generator file. It is, however, entirely up to the
+Configure places no rules on the command line, except that the first
+item must be the generator file. It is, however, entirely up to the
build file template to define exactly how those command lines should
be handled, how the output is captured and so on.
libobj2shlib(shlib => "PATH/TO/shlibfile",
lib => "PATH/TO/libfile",
objs => [ "PATH/TO/objectfile", ... ],
- deps => [ "PATH/TO/otherlibfile", ... ],
- ordinals => [ "word", "/PATH/TO/ordfile" ]);
+ deps => [ "PATH/TO/otherlibfile", ... ]);
'lib' has the intended library file name *without*
extension, libobj2shlib is expected to add that.
libraries (also *without* extension) this library
needs to be linked with. 'objs' has the list of
object files (also *without* extension) to build
- this library. 'ordinals' MAY be present, and when
- it is, its value is an array where the word is
- "crypto" or "ssl" and the file is one of the ordinal
- files util/libeay.num or util/ssleay.num in the
- source directory.
+ this library.
This function has a choice; it can use the
corresponding static library as input to make the
projects / openssl.git / blobdiff