• R
    Rework how our providers are built · dec95d75
    Richard Levitte 提交于
    We put almost everything in these internal static libraries:
    
    libcommon               Block building code that can be used by all
                            our implementations, legacy and non-legacy
                            alike.
    libimplementations      All non-legacy algorithm implementations and
                            only them.  All the code that ends up here is
                            agnostic to the definitions of FIPS_MODE.
    liblegacy               All legacy implementations.
    
    libnonfips              Support code for the algorithm implementations.
                            Built with FIPS_MODE undefined.  Any code that
                            checks that FIPS_MODE isn't defined must end
                            up in this library.
    libfips                 Support code for the algorithm implementations.
                            Built with FIPS_MODE defined.  Any code that
                            checks that FIPS_MODE is defined must end up
                            in this library.
    
    The FIPS provider module is built from providers/fips/*.c and linked
    with libimplementations, libcommon and libfips.
    
    The Legacy provider module is built from providers/legacy/*.c and
    linked with liblegacy, libcommon and libcrypto.
    If module building is disabled, the object files from liblegacy and
    libcommon are added to libcrypto and the Legacy provider becomes a
    built-in provider.
    
    The Default provider module is built-in, so it ends up being linked
    with libimplementations, libcommon and libnonfips.  For libcrypto in
    form of static library, the object files from those other libraries
    are simply being added to libcrypto.
    Reviewed-by: NMatt Caswell <matt@openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/10088)
    dec95d75
build.info 73 字节