+Intro
+=====
+
+This directory contains a few sets of files that are used for
+configuration in diverse ways:
+
+ *.conf Target platform configurations, please read
+ 'Configurations of OpenSSL target platforms' for more
+ information.
+ *.tmpl Build file templates, please read 'Build-file
+ programming with the "unified" build system' as well
+ as 'Build info files' for more information.
+ *.pm Helper scripts / modules for the main `Configure`
+ script. See 'Configure helper scripts for more
+ information.
+
+
Configurations of OpenSSL target platforms
==========================================
sys_id => System identity for systems where that
is difficult to determine automatically.
- cc => The compiler command, usually one of "cc",
+ 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
libraries into the final program.
+ cxx => The C++ compiler command, usually one of
+ "c++", "g++" or "clang++". This command is
+ also used when linking a program where at
+ least one of the object file is made from
+ C++ source.
cflags => Flags that are used at all times when
- compiling.
+ compiling C object files.
+ 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
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
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" and "unified".
+ Currently recognised build scheme is "unified".
For the "unified" build scheme, this item
*must* be an array with the first being the
word "unified" and the second being a word
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)
-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:
+It's also possible to depend on static libraries explicitly:
- ORDINALS[libcrypto]=crypto
+ DEPEND[foo]=libsomething.a
+ DEPEND[libbar]=libsomethingelse.a
-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.
+This should be rarely used, and care should be taken to make sure it's
+only used when supported. For example, native Windows build doesn't
+support build static libraries and DLLs at the same time, so using
+static libraries on Windows can only be done when configured
+'no-shared'.
One some platforms, shared libraries come with a name that's different
from their static counterpart. That's declared as follows:
"libbar" everywhere?), it does make sense when it can be used
conditionally. See a little further below for an example.
+In some cases, it's desirable to include some source files in the
+shared form of a library only:
+
+ SHARED_SOURCE[libfoo]=dllmain.c
+
For any file to be built, it's also possible to tell what extra
include paths the build of their source files should use:
INCLUDE[foo]=include
-It's possible to have raw build file lines, between BEGINRAW and
-ENDRAW lines as follows:
+In some cases, one might want to generate some source files from
+others, that's done as follows:
+
+ GENERATE[foo.s]=asm/something.pl $(CFLAGS)
+ 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 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.
+
+Sometimes, the generator file itself depends on other files, for
+example if it is a perl script that depends on other perl modules.
+This can be expressed using DEPEND like this:
+
+ DEPEND[asm/something.pl]=../perlasm/Foo.pm
+
+There may also be cases where the exact file isn't easily specified,
+but an inclusion directory still needs to be specified. INCLUDE can
+be used in that case:
+
+ INCLUDE[asm/something.pl]=../perlasm
+
+NOTE: GENERATE lines are limited to one command only per GENERATE.
+
+As a last resort, it's possible to have raw build file lines, between
+BEGINRAW and ENDRAW lines as follows:
BEGINRAW[Makefile(unix)]
haha.h: {- $builddir -}/Makefile
echo "/* haha */" > haha.h
ENDRAW[Makefile(unix)]
-The word withing square brackets is the build_file configuration item
+The word within square brackets is the build_file configuration item
or the build_file configuration item followed by the second word in the
build_scheme configuration item for the configured target within
parenthesis as shown above. For example, with the following relevant
build hoho.h: echo "/* hoho */" > hoho.h
ENDRAW[build.ninja(unix)]
+Should it be needed because the recipes within a RAW section might
+clash with those generated by Configure, it's possible to tell it
+not to generate them with the use of OVERRIDES, for example:
+
+ SOURCE[libfoo]=foo.c bar.c
+
+ OVERRIDES=bar.o
+ BEGINRAW[Makefile(unix)]
+ bar.o: bar.c
+ $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
+ ENDRAW[Makefile(unix)]
+
See the documentation further up for more information on configuration
items.
perl functions in a perl code fragment enclosed with "{-" and "-}".
They are all expected to return a string with the lines they produce.
+ generatesrc - function that produces build file lines to generate
+ a source file from some input.
+
+ It's called like this:
+
+ generatesrc(src => "PATH/TO/tobegenerated",
+ generator => [ "generatingfile", ... ]
+ generator_incs => [ "INCL/PATH", ... ]
+ generator_deps => [ "dep1", ... ]
+ generator => [ "generatingfile", ... ]
+ incs => [ "INCL/PATH", ... ],
+ deps => [ "dep1", ... ],
+ intent => one of "libs", "dso", "bin" );
+
+ 'src' has the name of the file to be generated.
+ 'generator' is the command or part of command to
+ generate the file, of which the first item is
+ expected to be the file to generate from.
+ generatesrc() is expected to analyse and figure out
+ exactly how to apply that file and how to capture
+ the result. 'generator_incs' and 'generator_deps'
+ are include directories and files that the generator
+ file itself depends on. 'incs' and 'deps' are
+ include directories and files that are used if $(CC)
+ is used as an intermediary step when generating the
+ end product (the file indicated by 'src'). 'intent'
+ indicates what the generated file is going to be
+ used for.
+
src2obj - function that produces build file lines to build an
object file from source files and associated data.
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
""; # Make sure no lingering values end up in the Makefile
-}
+
+
+Configure helper scripts
+========================
+
+Configure uses helper scripts in this directory:
+
+Checker scripts
+---------------
+
+These scripts are per platform family, to check the integrity of the
+tools used for configuration and building. The checker script used is
+either {build_platform}-{build_file}-checker.pm or
+{build_platform}-checker.pm, where {build_platform} is the second
+'build_scheme' list element from the configuration target data, and
+{build_file} is 'build_file' from the same target data.
+
+If the check succeeds, the script is expected to end with a non-zero
+expression. If the check fails, the script can end with a zero, or
+with a `die`.