Comment by delta_p_delta_x

3 days ago

There is not some arbitrary notion of wheel reinvention just for browsers. Calling browsers 'just browsers' is doing their feature set a huge disservice: they are bona fide operating systems or virtual machines, which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more), and do a huge amount of sandboxing to guard against escalations.

Within Google, a Chromium build uses remote build execution by default, upstream Clang by default (for the latest features and fixes, and Chromium developers regularly contribute to LLVM), and needs to cross-compile easily for at least a dozen different OS-architecture triples (Linux x86-64, Linux ARM, macOS, Windows x86-64, Windows on ARM, iOS, Android x86-64, Android ARM, Android TV, some BSDs, etc).

Everything you've listed—from ninja, to Clang, to libraries with custom patches, to Clang releases, including requiring pre-releases sometimes—is optimised for Google's scale, rather than the lone warrior developer. What you call 'sane Linux defaults' (especially the examples you have listed: GCC, automake, so-called 'system libraries') are highly antagonistic to all of the above.

They may make life easy for the so-called 'default case' of desktop Linux (arguable; Chromium was first released on Windows, and secondly since desktop Linux's most common C library, glibc has an unstable ABI, making back-portability impossible), but make it incredibly hard to get out a project of such immense complexity. All of Chromium's tooling and 'complexity' was developed in response to the 'sane' defaults being not so sane after all.

To get a GCC cross-compile for a given set of architecture triples, one needs a complete graph of GCC toolchains targeting every pair of host and target. On the other hand Clang is natively a cross-compiler; pass in `--sysroot` and the host compiler will redirect for the target instantly. Automake (and the autotools in general) is slow as molasses compared to ninja. It is based on computing and compilation from the 1970s, and their defaults probe for long-since-dead string comparison functions that are expected to work by default nowadays on most hosted systems. Not to mention it has an extraordinarily complicated configure step[1], and an equally appalling macro-based configure language.

Ninja is purely declarative, and is not even meant to be human-readable, as it is a back-end for a variety of build generator tools (CMake, XMake, build2, Bazel (Blaze internally at Google), Meson, probably more). Google have in fact rewritten Ninja to be a remote-build-capable tool from the outset[2], and they call it Siso. Siso has more than halved my Android build times even compared to Ninja because of its incredible use of RBE.

Frankly I think it should be evident why they have opted for 'rewriting the world' including vendoring and modifying system libraries, as well as including efforts like Skia, ANGLE, and more: directly relying on 'system libraries' is painful. I mentioned GPU drivers. Imagine rewriting the same code over and over to have precisely the same behaviour on D3D, Vulkan, OpenGL, Metal, and every single vendor GPU driver on every single system (and there are a lot more on mobile than on desktop: ARM Mali, Qualcomm Adreno, Samsung Xclipse, Imagination PowerVR, Huawei, MediaTek; this is not even close to exhaustive, just look at the Khronos vendor list).

When comments like yours are made I wonder if there is ever a consideration beyond 'it makes the developer's life hard'. As developers, our ultimate target audience are the users of our software. We should be willing to do anything come hell or high water, even making the dev-ex extraordinarily convoluted, if it means the user experience will be the smoothest and fastest possible. Sure, there is a balance, but I believe it should be strongly skewed towards the user story first.

[1]: https://upload.wikimedia.org/wikipedia/commons/8/84/Autoconf...

[2]: https://chromium.googlesource.com/build/+/refs/heads/main/si...

15 comments

delta_p_delta_x

Reply
rcxdude  3 days ago

>glibc has an unstable ABI, making back-portability impossible

Of all the libraries to call out for this, glibc is not the one. It's basically the only library on linux that actually has a strong commitment to providing a stable ABI, with its own symbol versioning system to allow it. It is a bit of a PITA to compile for an older version of that ABI, but it's very possible to be compatible with glibc across a wide range of versions and distributions (I don't know why there isn't a flag to do it: the most widely supported option is compiling on a system with the oldest glibc you want to support, and there's some header hacks which claim to be able to avoid that).

It's everything else necessary to interact with the system (especially anything desktop/multimedia) that's wildly unstable.

  • delta_p_delta_x  3 days ago

    Fair response.

    I singled it out because I've been badly burnt by it in the past, and I dislike how it works compared to Win32. Back-targeting old glibc from newer (a very common case because developers tend to have newer distros than their users), requires either changes in source code (not build code, which is where it ought to be) to explicitly pin versions, or the ridiculousness of firing up an entire Docker container just for old glibc. It has regularly caused issues for things like Steam on Linux.

    • LtWorf  3 days ago

      If you build on random developer's machines rather than a unified build environment you've already failed at so many things that the glibc problem is certainly not your biggest concern.

      2 replies →

  • M95D  3 days ago

    All I can say is that Gentoo specifically forbids downgrading glibc. I think it's the only package where they did this. [1] The .ebuild is full of patches and workarounds.

    [1] See line 873. https://github.com/gentoo/gentoo/blob/master/sys-libs/glibc/...

    • rcxdude  3 days ago

      Yeah, that's forwards-compatibility, which is different. Something built targeting a newer version of glibc is unlikely to work with an older one. (and gentoo will by default build against the latest you have installed, so yeah, downgrading has a good chance of breaking near everything).

    • simoncion  3 days ago

      > All I can say is that Gentoo specifically forbids downgrading glibc.

      Nope. You're protected from accidentally doing it, not forbidden. Look:

        # I_ALLOW_TO_BREAK_MY_SYSTEM=yes emerge -1v =sys-libs/glibc-2.43-r4
  These are the packages that would be merged, in order:
  <snip>
  [ebuild     UD ] sys-libs/glibc-2.43-r4:2.2::gentoo [2.44-r3:2.2::gentoo] <snip>

  Total: 1 package (1 downgrade), Size of downloads: 0 KiB

  >>> Verifying ebuild manifests
  
  >>> Running pre-merge checks for sys-libs/glibc-2.43-r4
  
  >>> Emerging (1 of 1) sys-libs/glibc-2.43-r4::gentoo
   * glibc-2.43.tar.xz BLAKE2B SHA512 size ;-) ...           [ ok ]
   * glibc-2.43-patches-5.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ]
   * Checking whether python3_14 is suitable ...
   *   dev-lang/python:3.14 ...                              [ ok ]
   * Using python3.14 to build (via PYTHON_COMPAT iteration)
  >>> Unpacking source...
   * Checking general environment sanity.
   * Sanity check to keep you from breaking your system:
   *  Downgrading glibc is not supported and a sure way to destruction.
   * Performing simple compile test for ABI=amd64 ...
   <snip>

      If you don't set that environment variable, the downgrade blows up at the "Sanity check to keep you from breaking your system:" step with a message that includes a call stack that pretty much tells you how to override the safety check:

        * Call stack:
  *     ebuild.sh, line  143:  Called src_unpack
  *   environment, line 3570:  Called sanity_prechecks
  *   environment, line 3199:  Called die
  * The specific snippet of code:
  *               [[ ${I_ALLOW_TO_BREAK_MY_SYSTEM} = yes ]] || die "Aborting to save your system.";

darkwater  3 days ago

Fair enough for poor Google, if only they did not strong-armed Chrome on everyone's computer by leveraging their default search engine/home page position, their ads and pop-under "Try Chrome" that were plastered everywhere 15 years ago or so.

  • poly2it  3 days ago

    This is not really relevant within the discussion of Chromium's build system.

    • RetroTechie  3 days ago

      It is: builds being painful enough that it's near impossible for smaller distro's to maintain a Chromium package, is community-hostile in itself.

      A true community project is flexible w/ respect to dependencies, builds in a way that's doable by anyone who puts in some effort, and sends bugfixes in dependencies upstream so that -normally speaking- project can build against common (versions of) system libraries.

      Doing the exact opposite screams vendor lock-in disguised as an open source effort. Of course no surprise this coming from Google (also notice similarities with the Android project).

    • darkwater  3 days ago

      It's relevant because Chrome market dominance still has a very strong influence on websites working (tested?) only with Chrome. Add to that Google's NIH syndrome and its "move fast" mantra at the cost of interoperability with the wider Linux community and then both things are relevant.

      1 reply →

hulitu  3 days ago

> which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more),

No, they don't have to. The fact that someone decided that a browser shall run remote code (JS) is sad.