This fixes includes like <cxxabi.h> in Android ASAN builds.
Bug: skia:10165
Change-Id: Ieeff45b29cd527dd0a60ed21422378f5aa610cc7
Cq-Include-Trybots: luci.skia.skia.primary:Build-Debian10-Clang-arm64-Debug-Android_ASAN,Build-Debian10-Clang-arm-Debug-Android_ASAN
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/322906
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We've been stifling this on Clang builds but not GCC,
for no good reason.
Change-Id: I49d6059dcf7547d25ec83c507c92f115ab199b79
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/314677
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
I think this new slice will run on the iPhone11 but
none of the older iOS devices, including the iPad bots.
Bug: skia:10663
Change-Id: I99edeccdd4adc845d3a79d7960b932bff374e77f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/313073
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
It simplifies things to always build this way, to mimic how we're built
by clients, and to better approximate MSVC defaults. I'm not sure I
believe my old note about making stack traces worse on Linux.
Change-Id: I0554a58573074fc6ae030fa09e11976a718645b5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/307834
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
No real way around using -fsanitize-blacklist,
but we can change the rest.
Bug: 1101491
Change-Id: I3ec84bd2911b6cf6e77eac1c9d565a398bfcde77
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/305754
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Ia6f93673de9b4cb76c4b0655c55b374aef362cfa
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/305405
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 9eb89bac85.
Reason for revert: Repeated Android trybot failures
Encountering ASAN failures of the form:
=================================================================
==10276==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0xc3d2c5c0 in thread T5
#0 0xf0e43b58 (/system/lib/libclang_rt.asan-arm-android.so+0xbeb58)
#1 0xb2157736 (/data/local/tmp/dm+0x2df4736)
#2 0xb0de3b3c (/data/local/tmp/dm+0x1a80b3c)
#3 0xb0e0d036 (/data/local/tmp/dm+0x1aaa036)
#4 0xb0e0983e (/data/local/tmp/dm+0x1aa683e)
#5 0xb0e093ba (/data/local/tmp/dm+0x1aa63ba)
#6 0xb0e0cf6a (/data/local/tmp/dm+0x1aa9f6a)
#7 0xb0e09ca8 (/data/local/tmp/dm+0x1aa6ca8)
#8 0xb0e09420 (/data/local/tmp/dm+0x1aa6420)
#9 0xb0e0cf6a (/data/local/tmp/dm+0x1aa9f6a)
#10 0xb0e0983e (/data/local/tmp/dm+0x1aa683e)
#11 0xb0e14416 (/data/local/tmp/dm+0x1ab1416)
#12 0xb0e259a6 (/data/local/tmp/dm+0x1ac29a6)
#13 0xb0dcd37e (/data/local/tmp/dm+0x1a6a37e)
#14 0xb0dcc004 (/data/local/tmp/dm+0x1a69004)
#15 0xb02030ec (/data/local/tmp/dm+0xea00ec)
#16 0xaff381a8 (/data/local/tmp/dm+0xbd51a8)
#17 0xaff1eade (/data/local/tmp/dm+0xbbbade)
#18 0xaff255f4 (/data/local/tmp/dm+0xbc25f4)
#19 0xb0bea1e4 (/data/local/tmp/dm+0x18871e4)
#20 0xb0a46c30 (/data/local/tmp/dm+0x16e3c30)
#21 0xb0a45c9e (/data/local/tmp/dm+0x16e2c9e)
#22 0xb0a467b0 (/data/local/tmp/dm+0x16e37b0)
#23 0xf0e2cf8c (/system/lib/libclang_rt.asan-arm-android.so+0xa7f8c)
#24 0xf0c6f502 (/system/lib/libc.so+0x63502)
#25 0xf0c29f26 (/system/lib/libc.so+0x1df26)
Address 0xc3d2c5c0 is a wild pointer.
SUMMARY: AddressSanitizer: bad-free (/system/lib/libclang_rt.asan-arm-android.so+0xbeb58)
Thread T5 created by T0 here:
#0 0xf0e2cdc8 (/system/lib/libclang_rt.asan-arm-android.so+0xa7dc8)
#1 0xb0a4651a (/data/local/tmp/dm+0x16e351a)
==10276==ABORTING
Caught signal 6 [Aborted] (173MB RAM, peak 180MB), was running:
unit test Codec_PngRoundTrip
unit test AAClip
unit test Codec_Dimensions
unit test Codec_raw
unit test crbug_ossfuzz_21688_interfaceblock
unit test crbug_ossfuzz_21688_interfaceblock
Caught signal 6 [Aborted] (173MB RAM, peak 180MB), was running:
unit test Codec_PngRoundTrip
unit test AAClip
unit test Codec_Dimensions
unit test Codec_raw
unit test crbug_ossfuzz_21688_interfaceblock
Likely culprit:
unit test crbug_ossfuzz_21688_interfaceblock
+ >/data/local/tmp/rc
+ echo 1
Original change's description:
> Enable _LIBCPP_DEBUG in Clang for non-Xcode-based debug builds.
>
> Unlike _GLIBCXX_DEBUG, this is meant to not break the ABI.
> The libc++ bundled with Xcode does not contain debug symbols so we need
> to disable these checks on Mac/iOS.
>
> Change-Id: Ie4f18e247db9c405b2ce45f388c41dcac8104815
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297874
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,bsalomon@google.com,johnstiles@google.com
Change-Id: I3f717de26428abf9cb26f983b1e82379924419c2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297840
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Unlike _GLIBCXX_DEBUG, this is meant to not break the ABI.
The libc++ bundled with Xcode does not contain debug symbols so we need
to disable these checks on Mac/iOS.
Change-Id: Ie4f18e247db9c405b2ce45f388c41dcac8104815
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297874
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Some users of Skia want to build these with -I instead of -isystem, and
until now we've piggybacked it on werror, but it's still kind of
annoying to see warnings even if they're not fatal.
Change-Id: I5a349b2571adc2f94c75dc17317666ddc2dec373
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/297788
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Change-Id: I5c1e6d8fd52ecfe628a78569b4665a64e1499fa5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/296938
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Change-Id: Ifb47c6be05bffad4a42030f4375dcbe0fe313ae0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293656
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
I was hoping this might fix the issues I'm seeing in the dependent CL.
It doesn't, but it's probably worth rolling every few months anyway.
Change-Id: I6d748d9e1a5bf908df78e989a624f2dccb1bd189
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293604
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This is an Android request for our public headers,
much like warning about unused parameters. See bug.
In general I've made two kinds of source changes:
1) more commonly, explicitly cast to the type which
is being implicitly cast to at head;
2) less commonly, flip signedness of a value we're
storing to match how it's used more smoothly.
Much of this is self inflicted inconsistent use of size_t, unsigned,
int, int32_t, uint32_t, etc. SkTArray is particularly tricky because
of its std::vector half-compatibility. E.g. resize() takes size_t,
but operator[] takes int. ¯\_(ツ)_/¯
Bug: skia:9847
Change-Id: I64626a529e1662b3d3020bc03d477fc641eda544
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/293436
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
We don't have any way to test these, and we do have to
go a little out of our way to maintain these builds.
Change-Id: Ie191ee26753b719f6ee22264d63fbe4252e69bd5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/290840
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
- Lots of skstd::foo is now std::foo since C++14.
- Get rid of SK_WHEN(cond,T); std::enable_if_t<cond,T> is pithy enough.
- Move SkBitmaskEnum.h contents into sknonstd.
Change-Id: Ie5dc459405b1ff55e5b3ac57e70df7edd7cf38c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/286315
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This reverts commit e990fcc4b0.
Reason for revert: Build-Win-Clang-x86_64-Release-Shared
Original change's description:
> Enable deprecated-copy-dtor warning.
>
> In C++11 a user declared destructor still requires the compiler to
> implicitly default the copy constructor and copy assignment operator,
> but this is deprecated. Note that a user declared destructor suppresses
> the move constructor and move assignment operator; a user declared
> destructor exists if any '~Foo' method declaration appears inside
> 'class Foo' (even if defaulted); if the copy and move operations are the
> same then copy operations that take 'const Foo&' will do fine double
> duty as move operations.
>
> Clang seems to have an issue with this warning, in that it does not
> appear to distinguish between compiler defaulted and user defaulted
> destructors. As a result, it does not always warn when it should.
> There may yet be places in the code where a move operation is desired
> but may be suppressed because the implicitly defaulted moves are not
> declared because a destructor has been declared.
>
> This wraps dawn and shaderc configs in 'third_party' so that their
> headers will be included through '-isystem' in order to avoid the
> warnings generated by including their headers.
>
> Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
> Reviewed-by: Mike Klein <mtklein@google.com>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bsalomon@google.com,bungeman@google.com
Change-Id: Icd6a2487637d21fcf7c4c7ab7cba7a8adfda5afd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280836
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
In C++11 a user declared destructor still requires the compiler to
implicitly default the copy constructor and copy assignment operator,
but this is deprecated. Note that a user declared destructor suppresses
the move constructor and move assignment operator; a user declared
destructor exists if any '~Foo' method declaration appears inside
'class Foo' (even if defaulted); if the copy and move operations are the
same then copy operations that take 'const Foo&' will do fine double
duty as move operations.
Clang seems to have an issue with this warning, in that it does not
appear to distinguish between compiler defaulted and user defaulted
destructors. As a result, it does not always warn when it should.
There may yet be places in the code where a move operation is desired
but may be suppressed because the implicitly defaulted moves are not
declared because a destructor has been declared.
This wraps dawn and shaderc configs in 'third_party' so that their
headers will be included through '-isystem' in order to avoid the
warnings generated by including their headers.
Change-Id: I681524cd890d86305aa99b6b765a52113b4dfa4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280406
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
GCC 9 warns about this pessimizing-move. It isn't clear why clang isn't
as well.
GCC 9 has a working redundant-move diagnostic. Clang has an old (C++11
style) redundant-move diagnostic which only warns when moving a
parameter. The GCC warning conflicts with Clang's
return-std-move-in-c++11, which we want to keep until we can drop
support for older compilers. So just disable redundant-move warnings
until we can remove return-std-move-in-c++11.
This change allows us to compile without warnings on gcc 9.3.0.
Change-Id: If21fcfb2944ce49e27fc84d40805752895ae68cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279958
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
It wants a blank line before a comment, even though the comment isn't a
break.
Change-Id: I6a2988719942e5e72142b8484182c128392a4be8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/279842
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Ben Wagner <bungeman@google.com>
Unfortunately in clang 'deprecated' is both a set of warnings (at least
one of which we don't want) and a group of warnings (most of which we do
want). Leave the top level disabled, but re-enable all the warnings in
the group.
Most of the code changes are for the deprecated-copy diagnostic. In
C++11 implementing a copy constructor xor copy assignment operator
the default implementation of the other is still required to be the
default but is deprecated (the compiler can warn against doing this).
The idea is that if there was a need for a non-default copy constructor
or copy assignment operator then both should be implemented explicitly,
since it is unlikely that the default will do what is expected.
Note that the deprecated-copy-dtor has not yet been enabled as there
will need to be a lot more work to enable this diagnostic. Similar to
deprecated-copy, in C++11 when implementing a destructor the copy
constructor and copy assignment operator are still defaulted if not
declared, but this is also deprecated. The idea here is that if some
special handling is needed to destroy the object there is probably some
need to do something non-trivial when copying the object (or copying
should be disallowed).
Also, there are still some deprecated-declarations to clean up on
Android and Mac.
Change-Id: I5fc4b62713220e6f7d3724fd7342b4c8c74a3c67
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/278916
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This was a convenience for Cary to not have to use extra_cflags,
and iterferes with using prebuilt C++ code by breaking the ABI.
Change-Id: I9e14ec04106a0abf9b55e5803242c2eb226d6e3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/276445
Commit-Queue: Herb Derby <herb@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Herb Derby <herb@google.com>
AFAIK, we can replace a lot of preprocessor tests now that we have
[[attributes]] and compilers are supposed to ignore unknown attributes.
Let's see if it works. If this sticks I'll get the rest in a big CL.
-Wattributes and MSVC warning C5030 are kind of annoying as errors,
so turn them off. This does not bode well for rolling into clients.
Change-Id: I88b150bab746c5510ff94f604096bf0ee0c9f96a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271886
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Doesn't seem to trigger.
Change-Id: I481b90a4e7fa0a4badc9acff9df1ec232a62417d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271680
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This CL has a complicated back story, but it's concrete change is
simple, just turning the warning on and converting a bunch of
return foo;
to
return std::move(foo);
These changes are exclusively in places where RVO and NRVO do not apply,
so it should not conflict with warnings like -Wpessimizing-move.
Since C++11, when you return a named local and its type doesn't match
the declared return type exactly, there's an implicit std::move()
wrapped around the value (what I'm making explicit here) so the move
constructor gets an opportunity to take precedence over the copy
constructor. You can read about this implicit move here under the
section "automatic move from local variables and parameters":
https://en.cppreference.com/w/cpp/language/return#Notes.
This situation comes up for us with smart pointers: a function declares
its return type as std::unique_ptr<Base> or sk_sp<Base>, and we return a
std::unique_ptr<Impl> or sk_sp<Impl>. Those types don't match exactly,
so RVO and NRVO don't come into play. They've always been going through
move constructors, and that's not changed here, just made explicit.
There was apparently once a bug in the C++11 standard and compilers
implementing that which made these copy instead of move, and then this
sort of code would do a little unnecessary ref/unref dance for sk_sp,
and would entirely fail to compile for uncopyable std::unique_ptr.
These explicit moves ostensibly will make our code more compatible with
those older compilers.
That compatibility alone is, I think, a terrible reason to land this CL.
Like, actively bad. But... to balance that out, I think the explicit
std::move()s here actually help remind us that RVO/NRVO are not in play,
and remind us we're going to call the move constructor. So that C++11
standard bug becomes kind of useful for us, in that Clang added this
warning to catch it, and its fix improves readability.
So really read this all as, "warn about implicit std::move() on return".
In the end I think it's just about readability. I don't really hold any
hope out that we'll become compatible with those older compilers.
Bug: skia:9909
Change-Id: Id596e9261188b6f10e759906af6c95fe303f6ffe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271601
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Apply -fsanitize-recover=pointer-overflow to third_party code only.
I'm trying to keep Skia behaving the same, avoiding illegal nullptr+k:
- Add null check in SkJSON fast string path.
- Add null check (first alloc) and some comments to SkArenaAlloc.
- March an int index instead dst pointer in SkBase64.
Bug: skia:9731
Change-Id: I646635558ea63ded846b746f2a1f0b4f1e1eacff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/268109
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Clang 10 added a new check we and libjpeg-turbo fail.
We need to investigate these failures, but I don't
want that to stop us rolling clang_win.
Bug: skia:9731
Change-Id: Ifdbb16ea0e2bacd30547d4a82a839563a9496d9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/260948
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
I've landed fixes for most of these,
leaving -Wclass-memaccess as a TODO.
Bug: skia:9674
Change-Id: Ifb951bc66e022b48ff4b66e4555d3fe3c7ef5aaf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/257501
Reviewed-by: Ben Wagner aka dogben <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2619784eca0f7a4dd66f2db0104cb746d9266b4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/244369
Commit-Queue: John Rosasco <rosasco@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
With this change C++17 language features can be used in code that does
not need to be be included in client code (not in public headers or
the files they transitively include).
We haven't investigated the c++17ness of the standard libraries in use
by clients so proceed with caution on library features.
One thing discovered along the way: throw() in C++17 is now equivalent
to noexcept(true). Moreover, the noexcept-ness of a function is part of
its type in C++17. This means that if a header declares a function with
throw() and it is included in a cpp compiled with C++17 file it will have
a different type than if it is compiled in a file compiled with C++14 (or
earlier) and you can get linker errors. Here is a change we had to make
as a result of this:
https://skia.googlesource.com/skia.git/+/4d0fe38f29388ef0aa6893d1d4fc237e758dd11f%5E%21/#F0
Change-Id: I996f2237fdd6b49e2e4cc8d3ff6db9dd536eafd8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/235022
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
With XCode 11 there is no more /usr/include directory. This
does not affect the XCode compilers, but does make goma compiler
break. This finds the system includes the same way that the iOS
builds currently do.
The gn_to_bp.py tool runs gn with target_os == mac, but host_os != mac.
In that case, the xcrun tool can not run, so make xcode_sysroot = "". This will
allow the xcode compilers to work when using the android.bp to build things.
TESTED:
builds on mac with and without goma
Change-Id: I9de6797c32760c59e62fe5ac505a3404e5eaf8e9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/249537
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
We've failed to get these bots to report where issues happen
any more finely than the name of the executable, which makes
them a real pain to fix when they go red.
We don't expect we'll be able to run cleanly in this mode for
long without bots enforcing it, so remove support from GN too.
Change-Id: Ie86f0cbf2f5f859ac2ddb869da7e5b8d31b33fa0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/237195
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I127c979670c3dc7dac2e35908a795afbdefca8f6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234902
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
If you just use the right compiler driver wrapper, recent NDKs automate
lots of the stuff we used to have to do ourselves.
Simplifying further, bump baseline ndk_api from 16 (Jellybean) on 32-bit
machines and 21 (Lollipop) on 64-bit to 21 across the board. This makes
using libc++ a lot easier, as it hooks into a bunch of APIs that were
added in 18 and 21. There's probably some way to work around this, but
the easiest thing is to just roll up.
Tested building {x86,arm}x{32,64} from a Linux host,
and running { arm}x{32,64}.
Kind of flailing around in later CLs trying to get linking not to hang
on Windows. I figure it's got something to do with lld?
Cq-Include-Trybots: skia.primary:Build-Win-Clang-arm64-Release-Android
Change-Id: I340b06fb9d372281146679d932417aaba3196045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225506
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Something's trying to link libc++.so by default,
so ask it to link libc++.a with -static-libstdc++.
Either way, the linker can't find libc++ without
adding another library directory path.
I think both changes should be harmlessly ignored
before r20.
Change-Id: I5b67e1dcb8b40548dae5a8300151e4392ae551f9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225436
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
-dead_strip works just fine there without those flags,
and they interfere with embedded bitcode.
Change-Id: If3766d245334fd9fa275e90fe67216ababafcecb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222450
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will ensure that the headers from the dependencies will have
precedent over system headers, thus preventing situations where system
headers will block dependency headers and prevent compilation.
Change-Id: I0d480a6d3898f2da99cf2706c5335aaac05b4e4d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220276
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Start out with spinlock. I tried to be more extensive, but some
of our abstractions confused the analysis. Will expand further
in following CLs.
Change-Id: I3e320c957d8ef427065a2b7e7d2187b7c6b0aef1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/213060
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Most external users complain about -Werror,
and I've heard anecdotally that devs find it annoying too.
This turns it off by default, but keeps it on the bots.
Change-Id: I6e87c92215261ebf6e961f816177386d5d58f28e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209787
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Nothing too tricky...
1) tell clang-cl to --target=arm64-windows
2) work around minor libpng issue temporarily
Change-Id: I4f0d792438610268821b67b92caf08fd78dcec4f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/208882
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
These changes let us build a non-official component build on Windows,
using either MSVC or clang
Change-Id: Ia3279aa19e007e70ff28925ff70a0bfe8144d96f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/207307
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I've been setting this in extra_cflags for a couple years...
maybe it's time everyone gets color in their warnings.
Change-Id: I1fed38a521fe9331b60fbb0688d39b5188a86aca
Reviewed-on: https://skia-review.googlesource.com/c/196360
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Just a few strays.
Change-Id: Ib209bc8dd228850b837b850dce14967a2112593e
Reviewed-on: https://skia-review.googlesource.com/c/191161
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
