Revert "android: Don’t use _FILE_OFFSET_BITS=64 until API 21" This reverts commit 88e056258a01450b07414642fa5fb98493c1f6ce (although an updated comment in build/common.gypi is retained). Refuting my last-week-self, who wrote: > android: Don’t use _FILE_OFFSET_BITS=64 until API 21 > > There’s enough brokenness around this that it’s not worthwhile to > pretend to support it. > > This has always been a bit of a cat-and-mouse game since Android began > introducing unified headers, and as of NDK r16, it’s broken again. Last week’s fix was found to be incomplete, because _FILE_OFFSET_BITS=64 is broken even at API 21 with certain interfaces such as those in <stdio.h>. A more targeted fix was discovered at https://crrev.com/c/811204, which allows _FILE_OFFSET_BITS=64 to be maintained in most places, disabling it only where necessary. So I’m back in the cat-and-mouse game, I suppose. Bug: crashpad:211 Change-Id: I0e0d15252ca8cd73f46bd44326b3653b9cc0cb6e Reviewed-on: https://chromium-review.googlesource.com/811206 Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is mini_chromium, a small collection of useful low-level (“base”) routines from the Chromium open-source project. Chromium is large, sprawling, full of dependencies, and a web browser. mini_chromium is small, self-contained, and a library. mini_chromium is especially useful as a dependency of other code that wishes to use Chromium’s base routines. By using mini_chromium, other projects’ code can function in a standalone environment outside of Chromium without having to treat all of Chromium as a dependency. When building as part of Chromium, those projects’ code can use Chromium’s own (non-mini_chromium) base implementation.
Code provided in mini_chromium provides the same interface as the equivalent code in Chromium.
While it’s a goal of mini_chromium to maintain interface compatibility with Chromium’s base library for the interfaces it does implement, there’s no requirement that it use the same implementations as Chromium’s base library. Many of the implementations used in mini_chromium are identical to Chromium’s, but many others have been modified to eliminate dependencies that are not desired in mini_chromium, and a few are completely distinct from Chromium’s altogether. Additionally, when mini_chromium provides an interface in the form of a file or class present in Chromium, it’s not bound to provide all functions, methods, or types that the Chromium equivalent does. The differences noted above notwithstanding, the interfaces exposed by mini_chromium’s base are and must remain a strict subset of Chromium’s.
Crashpad is the chief consumer of mini_chromium.
Mark Mentovai
mark@chromium.org