Tag: glibc (Page 1 of 4)

A short history of providing Chromium on Slackware.
I have scripted the compilation process in such a way that you can compile the Chromium sources into both chromium and chromium-ungoogled packages for Slackware using the same chromium.SlackBuild script. I compile the packages on Slackware 15.0 and use the same resulting package for both Slackware 15.0 and -current. This is a simple matter of economics – it takes half a day to compile a single package and when I can only validate and run in the evenings, every compilation effectively takes one full day.

The Google developers themselves compile these same Chromium sources into the official Chrome browser binaries using modified, customized versions of the Clang and Rust compiler toolchains to do so. They ship 64bit binaries of both those toolchains inside the Chromium source code tarballs, for both X86 and ARM architectures. No 32bit binaries have been included for a long time now. All of these binaries have been built on a somewhat older Debian release so that they are compatible with modern distros and just work.

As a Chromium packager, I can use these embedded binaries to ensure that I won’t run into source code incompatibilities, but then that only works for 64bit packages. For the 32bit packages I have always been relying on Slackware’s own 32bit versions of Clang and Rust as shipped with Slackware itself. Pat has been so kind to provide recent versions of llvm, rust and rust-bindgen for Slackware 15.0 in its ./extra and ./testing subdirectories, and he keeps doing that until today. Probably because he needs these to compile Mozilla Firefox 🙂 But hey, I profit.
Compiling Chromium using the Slackware native compilers has its own challenges but I have always found ways to deal with that.

Until now.

To compile the Chromium source code, Google has introduced a new tool, crubit, which aims to integrate the C++ and Rust ecosystems. It is a bidirectional bindings generator for C++ and Rust. In the Chromium 152 source code, only the “cc_bindings_from_rs” tool of crubit is being used, but in future also the reverse bindings counterpart “rs_bindings_from_cc” will be added.
The problem I have with this, is that Google compiled this “cc_bindings_from_rs” tool on a modern (Debian?) distro and thereby introduced a dependency on glibc 2.34. Slackware 15.0 contains glibc 2.33 and there you have it. The “cc_bindings_from_rs” program refuses to run on Slackware 15.0.
I have spent considerable time trying to compile crubit on Slackware 15.0 using either the Slackware native compilers or even Google’s own embedded compilers inside the Chromium source code, and have failed to produce a binary that works on Slackware 15.0.

Other measures were required.
The challenge I faced is two-fold:

1. I cannot use the embedded “cc_bindings_from_rs” on Slackware 15.0
2. I cannot compile a native Slackware version of it either

And these have multiple consequences. I can try to find a way to make that program run on Slackware 15.0 but it’s still a 64bit binary so I cannot solve the problem for the 32bit Chromium anyway if I cannot compile a native 32bit binary for “rs_bindings_from_rs“.
The way I tackled this is as follows. First I extracted a Slackware-current 64bit “aaa_glibc-solibs” package into the filesystem of my Slackware 15..0 compile box:

mkdir -p /opt/glibc-current/lib64
tar -C /opt/glibc-current/ -xf aaa_glibc-solibs-2.42-x86_64-2.txz
cd /opt/glibc-current/
rm -r install sbin usr
mv -i lib64/incoming/* lib64/
rmdir lib64/incoming

This is a one-time action. These files will remain there for future compilations. And now I have all of the newer glibc libraries (libc.so.6 and others) and the loader (ld-linux) that I need for Chromium, conveniently out of the way so that they do not affect the Slackware 15.0 system.
Then I need to convince the “rs_bindings_from_rs” tool to look at “/opt/glibc-current/lib64/” when  it wants to load glibc libraries. For this purpose, I added the following block inside the chromium.SlackBuild script.

# ---
GLIBC_COMPAT=${GLIBC_COMPAT:-/opt/glibc-current/lib64}
RUSTTC="$TMP/tmp-$PRGNAM/${SRCNAM}-${VERSION}/third_party/rust-toolchain"
CBFR="${RUSTTC}/bin/cc_bindings_from_rs"
if [ -x "$CBFR" ] && ! "$CBFR" --help >/dev/null 2>&1 ; then
  echo "-- Wrapping cc_bindings_from_rs to use $GLIBC_COMPAT."
  mv "$CBFR" "$CBFR.real"
  cat > "$CBFR" <<EOF
#!/bin/bash
exec $GLIBC_COMPAT/ld-linux-x86-64.so.2 \\
--library-path $GLIBC_COMPAT:$RUSTTC/lib \\
"$CBFR.real" "\$@"
EOF
  chmod +x "$CBFR"
  "$CBFR" --help >/dev/null 2>&1 && echo "-- cc_bindings_from_rs OK." \
  || { echo "-- ERROR: cc_bindings_from_rs still not runnable." ; exit 1 ; }
fi
# ---

What this does, is check whether the “cc_bindings_from_rs” tool actually runs (on Slackware-current it will run without issue) and if it fails because of the missing glibc symbols, create a wrapper script which ensures that the newer glibc libraries take precedence over Slackware’s own glibc, only for this particular binary. If “cc_bindings_from_rs” still fails to run, the script will abort.

This solves issue number 1.  But for a package build on 32bit Slackware 15.0 I would still need to be able to compile a native 32bit “cc_bindings_from_rs” and that’s simply not possible right now.
The solution here, is to use the 64bit toolchain embedded in the Chromium source, just like I did for the 64bit Slackware package, but then using cross-compilation on a 64bit multilib Slackware 15.0 host with 32bit as the target architecture.
Guess what… the chromium.SlackBuild is already fully prepared to perform a cross-compilation. All it needs is that you set the variable CROSS32 to the value “YES”. The Clang and Rust toolchains that are embedded in the Chromium source code are fully capable of cross-compiling. You do need to turn your 64bit Slackware host into a full multilib system following the instructions.

The command-line that compiles a 32bit chromium-ungoogled package then becomes:

CROSS32=YES BUILD_CLANG=1 USE_UNGOOGLED=1 ./chromium.SlackBuild

Hope this helps if you want to try this yourself and have been struggling with the new requirements.

Cheers, Eric