Since `$config{version}` and `$config{version_num}` were removed
in commit 3a63dbef15, the configure output displays an empty
version number string in parentheses instead of the version number.
This pull request fixes that by adding new config variables
`version` and `full_version`, analogous to `OPENSSL_VERSION_STR`
and `OPENSSL_FULL_VERSION_STR`.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7841)
We're strictly use version numbers of the form MAJOR.MINOR.PATCH.
Letter releases are things of days past.
The most central change is that we now express the version number with
three macros, one for each part of the version number:
OPENSSL_VERSION_MAJOR
OPENSSL_VERSION_MINOR
OPENSSL_VERSION_PATCH
We also provide two additional macros to express pre-release and build
metadata information (also specified in semantic versioning):
OPENSSL_VERSION_PRE_RELEASE
OPENSSL_VERSION_BUILD_METADATA
To get the library's idea of all those values, we introduce the
following functions:
unsigned int OPENSSL_version_major(void);
unsigned int OPENSSL_version_minor(void);
unsigned int OPENSSL_version_patch(void);
const char *OPENSSL_version_pre_release(void);
const char *OPENSSL_version_build_metadata(void);
Additionally, for shared library versioning (which is out of scope in
semantic versioning, but that we still need):
OPENSSL_SHLIB_VERSION
We also provide a macro that contains the release date. This is not
part of the version number, but is extra information that we want to
be able to display:
OPENSSL_RELEASE_DATE
Finally, also provide the following convenience functions:
const char *OPENSSL_version_text(void);
const char *OPENSSL_version_text_full(void);
The following macros and functions are deprecated, and while currently
existing for backward compatibility, they are expected to disappear:
OPENSSL_VERSION_NUMBER
OPENSSL_VERSION_TEXT
OPENSSL_VERSION
OpenSSL_version_num()
OpenSSL_version()
Also, this function is introduced to replace OpenSSL_version() for all
indexes except for OPENSSL_VERSION:
OPENSSL_info()
For configuration, the option 'newversion-only' is added to disable all
the macros and functions that are mentioned as deprecated above.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
It's being replaced with constant-time alternative.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7589)
We only convert lowercase .s to .asm, that turned out not to be sufficient.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7703)
Mingw and Cygwin builds install the DLLs in the application directory,
not the library directory, so ensure that one is created for them when
installing the DLLs.
Fixes#7653
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7654)
We only had the main 'install' target depend on 'all'. This changes
the dependencies so targets like install_dev, install_runtime_libs,
install_engines and install_programs depend on build targets that are
correspond to them more specifically. This increases the parallel
possibilities.
Fixes#7466
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7583)
When trying 'make -j{n} install', you may occasionally run into
trouble because to sub-targets (install_dev and install_runtime) try
to install the same shared libraries. That makes parallel install
difficult.
This is solved by dividing install_runtime into two parts, one for
libraries and one for programs, and have install_dev depend on
install_runtime_libs instead of installing the shared runtime
libraries itself.
Fixes#7466
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7583)
This adds a keyword SUBDIRS for build.info, to be used like this:
SUBDIRS=foo bar
This tells Configure that it should look for 'build.info' in the
relative subdirectories 'foo' and 'bar' as well.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7558)
This simple fix allows the following construct:
PROGRAMS=foo
SOURCE[foo]=foo.c bar.c
DEFINE[foo]=FOO=1 BAR=0
These will trickle down to the build of object files, so building
foo.o and bar.o will be done with these options: -DFOO=1 -DBAR=0
(exact syntax depending on platform, of course)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)
Sometimes, some specific program or object file might need an extra
macro definition of its own. This allows that to be easily done.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7553)
This makes sure that any resulting directory target in the build files
also depend on object files meant for shared libraries.
As a side effect, we move the production of the dirinfo structure from
common.tmpl to Configure, to make it easier to check the result.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7452)
This excluses user from additional PATH adjustments in case NDK has
llvm-ar.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7443)
03ad7c009e failed if one didn't pass
explicit -D__ANDROID_API__=N :-(
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7443)
We made the build of foo.obj depend on foo.d, meaning the latter gets
built first. Unfortunately, the way the compiler works, we are forced
to redirect all output to foo.d, meaning that if the source contains
an error, the build fails without showing those errors.
We therefore remove the dependency and force the build of foo.d to
always happen after build of foo.obj.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7469)
This also gave enough reason to collect the stuff that's common for
all iOS config targets into the template "ios-common".
Fixes#7318
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7403)
When building shared libraries on Windows, we had a clash between
'libcrypto.lib' the static routine library and 'libcrypto.lib' the
import library.
We now change it so the static versions of our libraries get '_static'
appended to their names. These will never get installed, but can
still be used for our internal purposes, such as internal tests.
When building non-shared, the renaming mechanism doesn't come into
play. In that case, the static libraries 'libcrypto.lib' and
'libssl.lib' are installed, just as always.
Fixes#7492
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7496)
We only had targets for the "simple" shared library names (libfoo.so
and not libfoo.so.x.y on Unix, import library libfoo.lib but not
libfoo.dll on Windows). This has created some confusion why it wasn't
possible to rebuild the less "simple" name directly (just as an
example, someone who mistook the import library on Windows for a
static library, removed the DLL and then found it was difficult to
rebuild directly), so we change the target to include all possible
names.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7451)
When looking at configured macro definitions, we must look at both
what comes from the config target AND what comes from user
configuration.
Fixes#7396
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7402)
Some modules are built with case insensitive (uppercase) symbols on
VMS. This needs to be reflected in the export symbol vector.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7347)
Rewrite util/mknum.pl to become cleaner, and to use the separate
generic C header parsing module, as well as the separate ordinals
manipulation module.
Adapt the build files.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7191)
Move the .num updating functionality to util/mknum.pl.
Rewrite util/mkdef.pl to create .def / .map / .opt files exclusively,
using the separate ordinals reading module.
Adapt the build files.
Adapt the symbol presence test.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7191)
The generation of linker scripts was badly balanced, as all sorts of
platform dependent stuff went into the top build.info, when that part
should really be made as simply and generic as possible.
Therefore, we move a lot of the "magic" to the build files templates,
since they are the place for platform dependent things. What remains
is to parametrize just enough in the build.info file to generate the
linker scripts correctly for each associated library.
"linker script" is a term usually reserved for certain Unix linkers.
However, we only use them to say what symbols should be exported, so
we use the term loosely for all platforms. The internal extension is
'.ld', and is changed by the build file templates as appropriate for
each target platform.
Note that this adds extra meaning to the value of the shared_target
attribute.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7333)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7277)
With the change to have separate object files by intent, VMS name
mangling gets done differently. While we previously had that for
libraries only, we must now turn that on generally for our programs,
because some of them depend in internal libraries where mangled names
are all that there is.
Dynamic modules are still built with non-mangled names, which is good
enough to show that it's possible to build with our public libraries
using our public headers.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7208)
The possibility to do this was killed when we started producing object
file names with encoded intention (and possibly different builds), and
leads to build errors.
With that, 'libobj2shlib' is renamed to 'obj2shlib' to reflect this
design change. The old name is still used if the new one isn't
available, for the sake of backward compatibility.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7198)
This is in preparation for having separate CFLAGS variables for static
and for shared library builds.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
This will allow to have different object files for different products,
even if they share the same source code, and possibly different builds
for those different object files.
For example, one can have something like this:
SOURCES[libfoo]=cookie.c
INCLUDES[libfoo]=include/foo
SOURCES[libbar]=cookie.c
INCLUDES[libbar]=include/bar
This would mean that the object files and libraries would be build
somewhat like this:
$(CC) -Iinclude/foo -o libfoo-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libfoo.a libfoo-lib-cookie.o
$(CC) -Iinclude/bar -o libbar-lib-cookie.o cookie.c
$(AR) $(ARFLAGS) libbar.a libbar-lib-cookie.o
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
Instead, use the include settings from the products later in the process,
making it possible to have different includes for two different libraries
that share the same source code.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7159)
-path is non-portable extension, fortunately it's possible to express
.git subdirectory exclusion with -prune.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7004)
This allows the original path to be displayed when it's shown
to be invalid, so the user can relate without question.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6925)
Extra slashes in paths are permissible in Unix-like platforms...
however, when compared with the result from 'which', which returns
canonical paths, the comparison might fail even though the compared
paths may be equivalent. We make the NDK path canonical internally to
ensure the equivalence compares as equal, at least for the most
trivial cases.
Fixes#6917
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6924)
