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.
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.
ld complains about mixing device and simulator objects in the
tvOS target. Reason is that "tvos_version_min" seems to imply a
device target, whereas simulator must use "tvos_simulator_version_min"
instead.
The stupid part of it is that ld displays a warning in iOS:
ld: warning: URGENT: -ios_version_min is invalid for architecture
x86/x86_64, inferring -ios_simulator_version_min. This will be an error
in the future.
whereas stops abruptly in tvOS:
ld: building for tvOS, but linking in object file built for tvOS
Simulator, file 'obj/a_d2i_fp.o' for architecture x86_64
ld should stop and avoid any poorly explained nonsense.
Davide De Rosa
Andreas Verhoeven
Alexei Lozovsky
Stephen Hinton
Felix Schulze
mconintet
Jason Lam
Felix Schulze
dapperstout
Pieter Claerhout