This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: I3b33a03b4a9a14b76d55fe12f8cdefec4b3c3664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205633
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Like HOST_ARCH_*, HOST_OS_* describes the OS the VM is running on, which may be different from the OS the VM is generating code for during AOT compilation.
Currently we conflate the two when emitting AOT as assembly, and we get away with it because Flutter only uses assembly for targeting iOS and one can only target iOS from a Mac, but we expect to use assembly for Android as well so native tools can unwind Dart frames.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2750843003 .
First, the look for trusted root certificates
in standard locations on the file system
(/etc/pki/tls/certs/ca-bundle.crt followed by
/etc/ssl/certs), and only if these do not exist
will we fall back on the compiled-in trusted root
certificates. This behavior can be overridden
with the new flags --root-certs-file and
--root-certs-cache.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2346683003 .
Previously we would compile in implementaitions of native calls for
IO functions that would never be used. This CL provides implementations
that throw a Dart exception if they're called by mistake. It also uses
a DART_IO_DISABLED preprocessor define to clean up the build files and
check that we're not including code we shouldn't.
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1839463002 .
This works by using SSL_CTX_load_verify_locations in
SecurityContext._trustBuiltinRoots() to specify
/system/etc/security/cacerts as the certificate directory.
This saves about 240KB from a stripped ProductAndroidARM build.
This has the drawback that SSL_do_handshake will synchronously
hit the filesystem looking for root certs during its trust evaluation.
We call SSL_do_handshake directly from the Dart thread so that Dart
code can be invoked from the "bad certificate" callback called by
SSL_do_handshake. If there was no need to support this callback,
it would be easier to move the handshake to the IOService thread, and
thus remove the compiled-in certs without the need for blocking IO
on the Dart thread.
R=whesse@google.com
Review URL: https://codereview.chromium.org/1811583003 .
Ryan Macnak