Native GLIBC instead of Linuxbrew since 2.21

TL;DR: Compiling PostgreSQL extensions is much easier in YugabyteDB versions 2.21 and above, as native OS libraries are used.

YugabyteDB initially used Linuxbrew to create a consistent, portable build environment across various Linux distributions. Linuxbrew allowed the bundling of dependencies like GCC and Glibc, ensuring controlled builds across systems, including non-Glibc-based ones. This approach simplified dependency management and testing by allowing complete control over the build environment.

However, several challenges arose with Linuxbrew, like performance overhead (relying on outdated libraries), compatibility issues (especially when compiling PostgreSQL extensions to run on yugabyteDB), and maintenance complexity.

YugabyteDB used Linuxbrew only for x86_64 builds, but aarch64 used native OS libraries. Starting with version 2.21, YugabyteDB transitioned to native libraries for all builds.

Here are the supported Operating Systems:

Operating system support | YugabyteDB Docs

Operating systems supported by YugabyteDB and YugabyteDB Anywhere.

docs.yugabyte.com

Here is how to see the difference by running dd on two x86_64 images.

Version 2.19 used linuxbrew:

-bash-4.2# docker run --rm -it yugabytedb/yugabyte:2.19.3.0-b140 \
           ldd /home/yugabyte/bin/yb-tserver

        linux-vdso.so.1 (0x00007ffcbfb98000)
        librt.so.1 => /home/yugabyte/linuxbrew/lib/librt.so.1 (0x00007f5c9d7a5000)
        libresolv.so.2 => /home/yugabyte/linuxbrew/lib/libresolv.so.2 (0x00007f5c9d58d000)
        libm.so.6 => /home/yugabyte/linuxbrew/lib/libm.so.6 (0x00007f5c9d288000)
        libc.so.6 => /home/yugabyte/linuxbrew/lib/libc.so.6 (0x00007f5c9c8e7000)
        /home/yugabyte/lib/ld.so => /lib64/ld-linux-x86-64.so.2 (0x00007f5cb9a47000)
        libpthread.so.0 => /home/yugabyte/linuxbrew/lib/libpthread.so.0 (0x00007f5c9c6c8000)
        libdl.so.2 => /home/yugabyte/linuxbrew/lib/libdl.so.2 (0x00007f5c9c4c3000)

Version 2.23 uses native libraries from (AlmaLinux 8 used for this image) :

-bash-4.2# docker run --rm -it yugabytedb/yugabyte:2.23.0.0-b710 \
           ldd /home/yugabyte/bin/yb-tserver

        linux-vdso.so.1 (0x00007ffcea370000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f4a4f00d000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4a4edf5000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4a4ea73000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4a4e69d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4a54f53000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4a4e47d000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f4a4e279000)

The image is slightly smaller (you can strip the executables if the image size matters, but then you will not have all debug symbols to troubleshoot errors):

-bash-4.2# docker image ls
REPOSITORY            TAG             IMAGE ID       CREATED         SIZE
yugabytedb/yugabyte   2.23.0.0-b710   254a05710594   4 weeks ago     2.1GB
yugabytedb/yugabyte   2.19.3.0-b140   9474f15f0653   11 months ago   2.28GB

Here is how to check the version of GLIBC (GNU libc):

-bash-4.2# docker run --rm -it yugabytedb/yugabyte:2.23.0.0-b710 \
           ldd --version

ldd (GNU libc) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

YugabyteDB uses the native GLIBC libraries, so Yugabyte will validate the collations that depend on it. Most use 'libicu', but here are the collations provided by GLIBC:

yugabyte=# select collname from pg_collation 
           where collprovider = 'c';

  collname
------------
 C
 POSIX
 ucs_basic
 en_US.utf8
 en_US

Jeremy Schneider has built an excellent tool to validate this:

ardentperf / glibc-unicode-sorting

Collation Changes Across Linux Versions

Methodology

GNU C Library

There are two aspects to this analysis: comparing the results of actual sorts in en_US locale, and comparing the LC_COLLATE section of the Operating System locale data files.

Comparing the results of actual sorts should catch any changes to default sorting which is not defined in the OS collation data. A simple perl script is used to generate a text file containing 91 different strings for every legal unicode character. The unix "sort" utility processes this file with the locale configured to en_US for collation. This process is repeated on each release from the past 10 years, and then the unix "diff" utility is used to compare the sorted output files and count how many characters have different positions after sorting. The results show how many individual code points have changed positions in the sorted data across different Operating System releases…

View on GitHub