You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
libandroid_support is currently coupled to libc++, but the headers are used unconditionally. This means that decls for things in libandroid_support are always present, so in the rare cases where libc++ isn't used (C only, or C++ builds that explicitly don't use the stdlib), using the functions that are provided by libandroid_support leads to degraded diagnostics (an undefined reference when linking instead of a "that API was added in $API_LEVEL" message).
Since the headers are there anyway, it might be good to always use libandroid_support rather than only when libc++ is used. It'd let us clean up a lot and reduce C vs C++ behavior differences.
The text was updated successfully, but these errors were encountered:
libandroid_support is currently coupled to libc++, but the headers are used unconditionally. This means that decls for things in libandroid_support are always present, so in the rare cases where libc++ isn't used (C only, or C++ builds that explicitly don't use the stdlib), using the functions that are provided by libandroid_support leads to degraded diagnostics (an undefined reference when linking instead of a "that API was added in $API_LEVEL" message).
Since the headers are there anyway, it might be good to always use libandroid_support rather than only when libc++ is used. It'd let us clean up a lot and reduce C vs C++ behavior differences.
The text was updated successfully, but these errors were encountered: