Some vulnerability analysis tools look at this 'marketing version'
string to determine the version of OpenSSL library. Keep the actual
version there to make the tools happy. Otherwise they tend to treat
OpenSSL 1.0 to be massively vulnerable.
Since we don't have access to OPENSSL_VERSION from build-libssl.sh,
extract the version from OpenSSL header files.
It is also necessary to set matching minimum SDK version in Info.plist
file of the frameworks. Extract the version and replace it in Info.plist
by pattern.
We should set accurate minimum SDK version in produced dylibs. Otherwise
the individual versions of object files are ignored and we end up with
a file that may have higher minimum SDK version than requested.
Since here we don't have access to *_MIN_SDK_VERSION variables set in
build-libssl.sh, retrieve the minimum SDK version from the object files.
This give accurate information. Parse "otool -l" output for that. It's
more or less simple, once you account for peculiarities.
In some use cases it's necessary to support older systems. Currently
minimum SDK versions are set to reasonable defaults, but there is no
easy way to override them.
Introduce a new set of command-line flags to set different minimum SDK
versions, similar to how it's possible to override the default target
SDK version:
--min-macos-sdk
--min-ios-sdk
--min-tvos-sdk
--min-watchos-sdk
Also, output the selected minimum SDK version along with the target one
on the configuration readout. It makes it easier to confirm that the
configuration is the one you expect.
If we are not building macOS targets then the framework has not been
created and we not should go ahead with creating symlinks in it. Check
whether the framework directory is there, if it's not then don't attempt
to create symlinks.
Davide De Rosa
Andreas Verhoeven
Alexei Lozovsky
Davide De Rosa
Felix Schulze