Goal</th>	Method</th></tr></thead>
Know your binary's glibc requirement</td>	`objdump -T binary \| grep GLIBC</code></td></tr>`
Lower the requirement broadly</td>	Build against an older sysroot / container</td></tr>
Pin specific C symbols to old versions</td>	`.symver</code> directive in C code</td></tr>`
Pin symbols from Rust</td>	C shim with `.symver</code> via cc-rs</code></td></tr>`
Restrict all symbols via linker</td>	`--version-script</code> with version cap</td></tr>`
Verify on target</td>	Run in a container with the target glibc</td></tr> </tbody></table> The safest, most predictable approach is building against the oldest glibc you need to support</strong>. The `.symver</code> trick is useful for surgical fixes when you can't change your entire build environment.</p>` `A working demo with all techniques is at https://github.com/konifay/blogpost-demos/tree/main/2026-0002-glibc-symbol-versioning</a>.</p>` Resources glibc FAQ: Symbol Versioning</a></li> ELF Symbol Versioning — Ulrich Drepper</a></li> Cross-Compiling Rust for aarch64 on Fedora</a></li> Specifying glibc Version in Cargo Build</a></li> GNU ld --version-script</code> Documentation</a></li> </ul> Cross-Compiling a rust app for target aarch64 on host x86_64 using Fedora 42 2026-02-05T00:00:00+00:00 Cross-Compiling Rust for aarch64 on Fedora x86_64 Introduction Over the last several years, the cloud has shifted from being dominated by x86_64 and sprinkle of PowerPC based systems to including a significant share of aarch64 across all major hyperscalers. As a result, cross-compiling Rust projects for aarch64 on a Fedora x86_64 host — especially with real-world native library dependencies — is now more common.</p> Problem Statement With a heterogeneous system it becomes harder to quickly patch and upload a binary. Best case, your CI infra is also integrated with your CD infra and allows blue green testing, i.e. of an odd SIGSEGV such that you can test hypothesis quickly without much pain. However, many small to medium size teams do not have that luxury of a sophisticated deployment pipeline.</p> There are still options left, like compiling on a remote machine, compiling in qemu, all with their particular set of tradeoffs.</p> The most popular being musl, but musl suffers from a mediocre integration into buildtools, always failing in unexpected ways, and being difficult to get right consistently with dependencies that assume glibc presence.</p> For the immediate and fast cycle times, I do cross compile locally, and that's what we'll delve into.</p> Definition of Cross Compiling Cross compiling means building a binary on one machine (the host</strong>) that is intended to run on another machine or environment (the target</strong>). The difference can be CPU architecture (x86_64 vs aarch64), operating system (Linux vs Windows), or even libc (glibc vs musl).</p> Host</strong>: the system doing the compilation (your local workstation)</li> Target</strong>: the system where the binary will run (the server/device)</li> Architecture</strong>: the CPU instruction set (x86_64, aarch64, etc.)</li> </ul> In short: you compile on host</em> for a target</em> with a different architecture</em>, and that implies you need the right toolchain, headers, and libraries for the given target.</p> First steps Install the cross-compilation toolchain:</p> #</span></span> Add Rust aarch64 target</span> </span></span>rustup</span></span> target add aarch64-unknown-linux-gnu</span> </span> </span>#</span></span> Install aarch64 GCC cross-compiler</span> </span></span>sudo</span></span> dnf install gcc-aarch64-linux-gnu</span> </span></code></pre> See the Rust Cross-Compilation Guide</a> for more details on adding targets.</p> Now, if you thought</p> cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu</span> </span></code></pre> would be good to go, you are likely to be disappointed. It will work for a pure rust project. But reality doesn't quite comply.</p> Example Project In the following we shall assume our example has dependencies - either dynamically linked or statically linked - for which packages exist in the target specific distribution repositories, i.e. libsqlite3-devel.aarch64</code> exists in fedora:42</code>. We'll assume cargo</code> as our build tool of choice.</p> Solution: Sysroot Configuration What is Sysroot? It's really just a minimal filesystem for the target architecture. It contains a basic directory structure.</p> Location</strong>: /usr/aarch64-redhat-linux/sys-root/fc42/</code></li> Structure</strong>: Mirrors a typical Linux root with /usr/lib64</code>, /usr/include</code></li> Purpose</strong>: Provides headers and libraries for the target architecture</li> </ul> It does not</em> provide you the ability to execute aarch64 binaries on x86_64, for that you need an emulator like qemu.</p> How it's done When you specify --sysroot</code>, the compiler/linker searches there instead of /usr</code> on your host system.</p> Fedora provides a basic sysroot package for aarch64, and for a few others:</p> sysroot-aarch64-fc42-glibc.noarch Sysroot package for glibc, aarch64 architecture </span>sysroot-i386-fc42-glibc.noarch Sysroot package for glibc, i386 architecture </span>sysroot-ppc64le-fc42-glibc.noarch Sysroot package for glibc, ppc64le architecture </span>sysroot-s390x-fc42-glibc.noarch Sysroot package for glibc, s390x architecture </span>sysroot-x86_64-fc42-glibc.noarch Sysroot package for glibc, x86_64 architecture </span></code></pre> sudo</span></span> dnf install sysroot-aarch64-fc42-glibc.noarch</span> </span></code></pre> It contains a directory, just like a root-filesystem, but nothing can be executed since host and target differ in architecture.</p> Use dnf --installroot</code> to populate it with aarch64 packages1</a></sup>:</p> sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \ </span></span></span> --</span>releasever</span>=</span>42 \ </span></span></span> --</span>forcearch</span>=</span>aarch64 \ </span></span></span> --</span>use-host-config</span> \ </span></span></span> install sqlite-devel libgcc glibc-devel gcc</span> </span> </span>#</span></span> BUG: Create development symlink for libgcc_s.so since it's missing in fedora:42</span> </span></span>cd</span></span> /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64</span> </span>sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 libgcc_s.so</span> </span>cd</span></span> -</span> </span></code></pre> Key flags:</strong></p> --installroot</code>: Specifies the target root directory</li> --releasever</code>: Matches your Fedora version (42 in this example)</li> --forcearch</code>: Forces installation of aarch64 packages</li> --use-host-config</code>: Uses your host's repository configuration - which works as long as your /etc/yum.repos.d/.repo</code> files are parameterized across architecture</li> </ul> With the sysroot now in place, we need to ensure it's being picked up by rustc</code> as well as any gcc</code>/clang</code>/clang++</code> invocations as well as the linker.</p> For that we must provide the paths to the respective invocations via cargo.</p> Cargo Configuration Create or update .cargo/config.toml</code>2</a></sup> in your project or globally in ~/.cargo/config.toml</code>:</p> [</span>target</span>.</span>aarch64-unknown-linux-gnu</span></span>]</span> </span>#</span> you can skip `linker = ` if you're using `mold`[^3]</span> </span>linker</span></span> =</span> "</span>/usr/bin/aarch64-linux-gnu-gcc"</span></span> </span>rustflags</span></span> =</span> [</span>"</span>-C"</span></span>,</span> "</span>link-arg=--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>]</span> </span> </span>#</span> add the target specific sysroot flags for usage in `cc-rs`</span> </span>[</span>env</span></span>]</span> </span>CFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include"</span></span> </span>CXXFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++/15 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++ -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++/15/aarch64-redhat-linux"</span></span> </span>LDFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>PKG_CONFIG_SYSROOT_DIR</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>PKG_CONFIG_PATH</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/pkgconfig:/usr/aarch64-redhat-linux/sys-root/fc42/usr/share/pkgconfig"</span></span> </span>PKG_CONFIG_ALLOW_CROSS</span></span> =</span> "</span>1"</span></span> </span></code></pre> Note: include paths are still absolute</em> to the host filesystem, not relative to the sysroot. cc-rs honors target-suffixed env vars like CFLAGS_<target></code> or CFLAGS_<target_with_underscores></code>, so the example uses the underscore form to scope flags to aarch64 only. Cargo .cargo/config.toml</code> does not support target-specific env vars in [env]</code>, so the vars must be named with the target suffix themselves.3</a></sup></p> Why this is needed:</strong></p> The linker needs --sysroot</code> to find C runtime objects for the target architecture (Scrt1.o</code>, crti.o</code>, crtn.o</code>)</li> C/C++ compilation (from build scripts via i.e. cc-rs</code>) needs sysroot for various standard headers and linking to target architecture libraries Without these flags, the compiler/linker searches the host system and finds x86_64 libraries</li> </ul> </li> </ul> Building As per usual</p> cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu --</span>release</span></span> </span></code></pre> Container-Based Cross-Compilation If you don't use Fedora as your host OS, or want a somewhat reproducible build environment, use a container:</p> Containerfile.cross:</strong></p> Sets up a compilation environment (rust</code>, cargo</code>, gcc</code>, ..) as well as the aarch64</code> sysroot within</em> the container itself, so you'll need to modify it to your specific project needs!</p> FROM</span> fedora:42</span> </span> </span>#</span> Install build dependencies (including C++ cross-compiler and CMake) </span></span>RUN </span>dnf install -y \ </span> gcc \ </span> gcc-c++ \ </span> gcc-aarch64-linux-gnu \ </span> gcc-c++-aarch64-linux-gnu \ </span> sqlite-devel \ </span> make \ </span> curl \ </span> pkg-config \ </span> clang \ </span> cmake \ </span> git \ </span> && dnf clean all </span> </span>#</span> Copy rust-toolchain.toml to read the version </span></span>COPY</span> rust-toolchain.toml /tmp/rust-toolchain.toml </span> </span>#</span> Install Rust using rustup with version from rust-toolchain.toml </span></span>RUN </span>RUST_VERSION=$(grep '</span>^channel'</span></span> /tmp/rust-toolchain.toml \| awk -F'</span>"'</span></span> '</span>{print $2}'</span></span>) && \ </span> echo "</span>Installing Rust version: $RUST_VERSION"</span></span> && \ </span> curl --proto '</span>=https'</span></span> --tlsv1.2 -sSf https://sh.rustup.rs \| sh -s -- -y --default-toolchain "</span>$RUST_VERSION"</span></span> --profile minimal </span>ENV </span>PATH="</span>/root/.cargo/bin:${PATH}"</span></span> </span> </span>#</span> Set the default toolchain explicitly </span></span>RUN </span>RUST_VERSION=$(grep '</span>^channel'</span></span> /tmp/rust-toolchain.toml \| awk -F'</span>"'</span></span> '</span>{print $2}'</span></span>) && \ </span> rustup default "</span>$RUST_VERSION"</span></span> </span> </span>#</span> Verify rustup is working and add aarch64 target </span></span>RUN </span>rustup --version && rustup show && rustup target add aarch64-unknown-linux-gnu </span> </span>#</span> Setup sysroot with aarch64 dependencies </span></span>ENV </span>SYSROOT=/usr/aarch64-redhat-linux/sys-root/fc42 </span>RUN </span>dnf --installroot=${SYSROOT} \ </span> --releasever=42 \ </span> --forcearch=aarch64 \ </span> --use-host-config \ </span> install -y sqlite-devel libgcc glibc-devel gcc gcc-c++ libstdc++-devel openssl-devel pkgconf-pkg-config \ </span> && dnf clean all </span> </span>#</span> Verify pkg-config files exist </span></span>RUN </span>ls -la ${SYSROOT}/usr/lib64/pkgconfig/openssl.pc </span> </span>#</span> Create libgcc_s.so symlink (linker expects unversioned name) </span></span>RUN </span>ln -sf libgcc_s.so.1 ${SYSROOT}/usr/lib64/libgcc_s.so </span> </span>#</span> Create libstdc++.so symlink (CMake needs this for linking) </span></span>RUN </span>if [ -f ${SYSROOT}/usr/lib64/libstdc++.so.6 ]; then \ </span> ln -sf libstdc++.so.6 ${SYSROOT}/usr/lib64/libstdc++.so; \ </span> fi </span> </span>#</span> Set working directory </span></span>WORKDIR </span>/x </span> </span>#</span> Install oq for TOML manipulation </span></span>RUN </span>/root/.cargo/bin/cargo install oq </span> </span>#</span> Ensure cargo is in PATH for CMD </span></span>ENV </span>PATH="</span>/root/.cargo/bin:${PATH}"</span></span> </span> </span>#</span> Copy build entrypoint script </span></span>COPY</span> build-entrypoint.sh /usr/local/bin/build-entrypoint.sh </span>RUN </span>chmod +x /usr/local/bin/build-entrypoint.sh </span> </span>#</span> Default command - run build script </span></span>CMD </span>["</span>/usr/local/bin/build-entrypoint.sh"</span></span>] </span></code></pre> build-entrypoint.sh:</strong></p> The actual execution happening inside</em> the container - patching .cargo/config.toml</code>, building your binary.</p> #</span></span>!/bin/bash</span> </span></span>set</span></span> -</span>e</span></span> </span> </span>SYSROOT</span>=</span>"</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span></span> </span>#</span></span> Ensure .cargo/config.toml exists</span> </span></span>mkdir</span></span> -</span>p</span> .cargo</span> </span>if</span> [</span> !</span> -</span>f</span> .cargo/config.toml ]</span></span>;</span> then</span> </span> echo</span></span> "</span>Creating .cargo/config.toml..."</span></span></span> </span> touch</span></span> .cargo/config.toml</span> </span>fi</span> </span> </span>#</span></span> Patch .cargo/config.toml</span> </span></span>echo</span></span> "</span>Patching .cargo/config.toml for cross-compilation..."</span></span></span> </span>oq</span></span> -</span>i</span> toml -</span>o</span> toml \ </span></span></span> '</span>.target."aarch64-unknown-linux-gnu".linker = "aarch64-linux-gnu-gcc" \| </span></span></span> .target."aarch64-unknown-linux-gnu".rustflags = ["-C", "link-arg=--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>"] \| </span></span></span> .env.CFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.CXXFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.CXXLDFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.LDFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.PKG_CONFIG_SYSROOT_DIR = "'</span></span>$</span>SYSROOT</span></span>'</span>" \| </span></span></span> .env.PKG_CONFIG_PATH = "'</span></span>$</span>SYSROOT</span></span>'</span>/usr/lib64/pkgconfig:'</span></span>$</span>SYSROOT</span></span>'</span>/usr/share/pkgconfig" \| </span></span></span> .env.PKG_CONFIG_ALLOW_CROSS = "1"'</span></span> \ </span></span></span> .cargo/config.toml ></span> .cargo/config.toml.new</span> </span> </span>mv</span></span> .cargo/config.toml.new .cargo/config.toml</span> </span>echo</span></span> "</span>Configuration patched successfully."</span></span></span> </span> </span>#</span></span> Build for aarch64</span> </span></span>echo</span></span> "</span>Building for aarch64-unknown-linux-gnu..."</span></span></span> </span>cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu --</span>release</span></span> </span></code></pre> Shell Wrapper:</strong></p> Convenience helper, build the container using podman</code> and executing the build while sharing cargo cache and some binaries. If you're on OS X, it will need adjustments for mapping volumes.</p> </span>#</span></span> The `crisscross` function expects:</span> </span></span>#</span></span> - `rust-toolchain.toml` - To determine which Rust version to install</span> </span></span>#</span></span> - `Containerfile.cross` - Container build instructions</span> </span></span>#</span></span> - `build-entrypoint.sh` - Script that patches cargo config and runs build</span> </span></span>function</span> crisscross</span> {</span> </span></span> local</span> containerfile</span>=</span>"</span>$</span>{</span></span>1</span></span>:-</span></span>Containerfile.cross</span>}</span></span>"</span></span></span></span> </span></span> local</span> image_name</span>=</span>"</span>$</span>{</span></span>2</span></span>:-</span></span>crisscross:aarch64</span>}</span></span>"</span></span></span></span> </span></span> </span></span> podman</span></span> build -</span>t</span> "</span>$</span>image_name</span></span>"</span></span> -</span>f</span> "</span>$</span>containerfile</span></span>"</span></span> .</span> &&</span> \ </span></span></span> podman</span></span> run --</span>rm</span> -</span>v</span> .:/x:z -</span>v</span> ~</span></span>/.cargo:/root/.cargo:z "</span>$</span>image_name</span></span>"</span></span></span> </span></span> </span></span> echo</span></span> "</span>Build complete!"</span></span></span> </span></span> ls</span></span> -</span>lh</span> target/aarch64-unknown-linux-gnu/release 2</span>></span>/dev/null</span> \|\|</span> echo</span></span> "</span>No binary found"</span></span></span> </span></span>}</span></span> </span></code></pre> Usage: crisscross</code> or crisscross Containerfile.aarch64 my-cross-build-env-setup-containing-sysroot-oci-image:tag</code></p> A full working demo can be found at https://github.com/konifay/blogpost-demos/tree/main/2026-0001-cross-compile-rust-fedora</a>.</p> Enjoy!</p> Resources DNF5 Documentation</a> - See command reference for installroot usage</li> Rust Cross-Compilation Guide</a></li> Cargo Configuration Reference</a></li> pkg-config crate documentation</a></li> Specifying glibc Version in Cargo Build</a></li> mold - A Modern Linker</a></li> sysroot setup for gnome builder</a></li> </ul> Troubleshooting Guide Below is a comprehensive list of common issues, quirks, and gotchas encountered during cross-compilation.</p> Issue 1: Missing libgcc_s.so</code> Error:</strong></p> /usr/bin/aarch64-linux-gnu-ld: cannot find -lgcc_s: No such file or directory </span></code></pre> Typical offenders:</strong> toolchain/runtime pieces expected by C/C++ build systems and linkers.</p> Solution:</strong> The linker looks for libgcc_s.so</code> (without version suffix), but only libgcc_s.so.1</code> exists in the sysroot. Create a symlink:</p> sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libgcc_s.so</span> </span></code></pre> Issue 2: Missing standard headers (e.g., assert.h</code>) Error:</strong></p> c/blake3_impl.h:4:10: fatal error: assert.h: No such file or directory </span></code></pre> Typical offenders:</strong> build scripts using cc-rs</code> or C/C++ code in crates like blake3</code> that expect glibc headers.</p> Solution:</strong> Install glibc-devel</code> in the sysroot (see the dnf --installroot</code> command above). Ensure CFLAGS</code>/CXXFLAGS</code> include --sysroot</code> so headers resolve correctly.</p> Issue 3: Missing target libraries (e.g., SQLite, libpq, libgit2) Error:</strong></p> /usr/bin/aarch64-linux-gnu-ld: cannot find -lsqlite3: No such file or directory </span></code></pre> Typical offenders:</strong> native -sys</code> crates (sqlite</code>, libpq</code>, libgit2</code>) that expect target-arch -devel</code> packages.</p> Solution:</strong> Install the relevant -devel</code> packages in the sysroot via dnf --installroot</code>:</p> sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \ </span></span></span> --</span>releasever</span>=</span>42 \ </span></span></span> --</span>forcearch</span>=</span>aarch64 \ </span></span></span> --</span>use-host-config</span> \ </span></span></span> install -</span>y</span> sqlite-devel</span> </span></code></pre> Issue 4: OpenSSL Not Found (pkg-config fails) Error:</strong></p> Could not find directory of OpenSSL installation, and this `-sys` crate cannot </span>proceed without this knowledge. If OpenSSL is installed and this crate had </span>trouble finding it, you can set the `OPENSSL_DIR` environment variable for the </span>compilation process. </span> </span>Could not find openssl via pkg-config: </span>pkg-config has not been configured to support cross-compilation. </span></code></pre> Typical offenders:</strong> openssl-sys</code> and other crates that rely on pkg-config to locate headers/libs.</p> Solution:</strong> Install OpenSSL + pkg-config in the sysroot and configure the cross pkg-config environment:</p> sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \ </span></span></span> --</span>releasever</span>=</span>42 \ </span></span></span> --</span>forcearch</span>=</span>aarch64 \ </span></span></span> --</span>use-host-config</span> \ </span></span></span> install -</span>y</span> openssl-devel pkgconf-pkg-config</span> </span></code></pre> Add to .cargo/config.toml</code>:</p> [</span>env</span></span>]</span> </span>PKG_CONFIG_SYSROOT_DIR</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>PKG_CONFIG_PATH</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/pkgconfig:/usr/aarch64-redhat-linux/sys-root/fc42/usr/share/pkgconfig"</span></span> </span>PKG_CONFIG_ALLOW_CROSS</span></span> =</span> "</span>1"</span></span> </span></code></pre> Issue 5: Missing Development Symlinks Error:</strong></p> /usr/bin/aarch64-linux-gnu-ld: cannot find -lfoo: No such file or directory </span></code></pre> Where libfoo.so.X</code> exists in the sysroot but libfoo.so</code> symlink is missing.</p> Typical offenders:</strong> Any crate using cc-rs</code> or direct linking when -devel</code> packages don't create proper symlinks via dnf --installroot</code>.</p> Root cause:</strong> Development packages typically install versioned libraries (e.g., libfoo.so.1.2.3</code>) and a symlink libfoo.so</code> → libfoo.so.1.2.3</code>. However, when using dnf --installroot</code>, sometimes only the versioned library gets installed without the development symlink. The linker (ld</code>) searches for -lfoo</code> by looking for libfoo.so</code>.</p> Solution:</strong> Manually create symlinks in the sysroot:</p> cd</span></span> /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64</span> </span>#</span></span> Find the actual library version</span> </span></span>ls</span></span> -</span>la</span> libfoo.so</span></span> </span>#</span></span> Create the symlink</span> </span></span>sudo</span></span> ln -</span>sf</span> libfoo.so.1.2.3 libfoo.so</span> </span></code></pre> Common libraries requiring symlinks:</p> libgcc_s.so.1</code> → libgcc_s.so</code></li> libstdc++.so.6</code> → libstdc++.so</code></li> libssl.so.3</code> → libssl.so</code></li> </ul> Issue 6: CMake C++ Compiler Test Fails (Missing libstdc++) Error:</strong></p> The C++ compiler "/usr/bin/aarch64-linux-gnu-g++" is not able to compile a simple test program. </span>/usr/bin/aarch64-linux-gnu-ld: cannot find -lstdc++: No such file or directory </span></code></pre> Typical offenders:</strong> CMake-based crates (libz-ng-sys</code>, rocksdb</code>, snappy</code>) that invoke the linker directly and need the C++ runtime.</p> Solution:</strong> Install C++ standard library in the sysroot:</p> sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \ </span></span></span> --</span>releasever</span>=</span>42 \ </span></span></span> --</span>forcearch</span>=</span>aarch64 \ </span></span></span> --</span>use-host-config</span> \ </span></span></span> install -</span>y</span> gcc-c++ libstdc++-devel</span> </span></code></pre> Also ensure linker flags are set:</p> [</span>env</span></span>]</span> </span>CXXFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>LDFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span>CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span> </span></code></pre> Critical quirk:</strong> CMake may invoke the linker (aarch64-linux-gnu-ld</code>) directly instead of through the compiler wrapper. The linker needs unversioned .so</code> files (e.g., libstdc++.so</code>, not libstdc++.so.6</code>). Create symlinks:</p> sudo</span></span> ln -</span>sf</span> libstdc++.so.6 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libstdc++.so</span> </span>sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libgcc_s.so</span> </span></code></pre> Issue 7: CMake Linker Invocation Bypasses Compiler Flags CMake often bypasses compiler wrappers and invokes the linker directly. This means CFLAGS</code> and CXXFLAGS</code> may not propagate to the linking stage. You must set:</p> LDFLAGS_<target></code> - General linker flags</li> CMAKE_EXE_LINKER_FLAGS_<target></code> - CMake-specific linker flags</li> CXXLDFLAGS_<target></code> - C++ linker flags (for some build systems)</li> </ul> All should include --sysroot=/path/to/sysroot</code>.</p> Issue 8: Host vs Target Confusion Build scripts (build.rs</code>) run on the host</strong> architecture (x86_64), but they may compile code for the target</strong> architecture (aarch64). If a build script requires native tools like clang</code> or cmake</code>, install them on the host system:</p> dnf</span></span> install -</span>y</span> clang cmake #</span></span> Host tools</span> </span></span></span></code></pre> If the build script compiles C/C++ for the target, ensure cross-compilers are available and CFLAGS_<target></code> is set.</p> Issue 9: pkg-config Cross-Compilation By default, pkg-config</code> searches /usr/lib64/pkgconfig</code> on the host. For cross-compilation:</p> Set PKG_CONFIG_SYSROOT_DIR</code> to the target sysroot</li> Set PKG_CONFIG_PATH</code> to <sysroot>/usr/lib64/pkgconfig</code></li> Set PKG_CONFIG_ALLOW_CROSS=1</code> to bypass sanity checks</li> </ol> The pkg-config</code> crate supports target-specific variants of PKG_CONFIG_PATH</code>, PKG_CONFIG_LIBDIR</code>, and PKG_CONFIG_SYSROOT_DIR</code> using suffixes like _aarch64-unknown-linux-gnu</code> or _aarch64_unknown_linux_gnu</code>, plus HOST_</code>/TARGET_</code> prefixes. It only allows cross-compilation when PKG_CONFIG_SYSROOT_DIR</code> or PKG_CONFIG</code> is set; otherwise it refuses to run unless you force it with PKG_CONFIG_ALLOW_CROSS=1</code>.4</a></sup></p> Without these, openssl-sys</code> and similar crates will fail.</p> Issue 10: Binary Compatibility Binaries built with glibc are not portable</strong> across different glibc versions. If your target system runs Fedora 40 with glibc 2.39, but you build against Fedora 42 with glibc 2.41, the binary may fail with "version `GLIBC_2.41' not found".</p> Solutions:</strong></p> Explicitly provide a glibc API version5</a></sup> - glibc provides versioned symbols</li> Match the Fedora version to your deployment target</li> Use musl for static binaries (though this has its own challenges)</li> </ul> tl;dr Proper sysroot setup with --installroot</code></li> </ol> Installing all</strong> native dependencies in the sysroot</li> </ul> Cargo configuration to pass sysroot to compiler and linker invocations</li> Apply specific quirks for your set of libraries</li> </ol> The same principles apply to rust/C/C++ cross-compilation.</p> Footnotes ^1</sup>See DNF5 Documentation</a> for more on installroot usage.</p> </div> ^2</sup>See Cargo Configuration Reference</a> for all available options.</p> </div> ^6</sup>mold</a> is a fast modern linker with built-in cross-compilation support.</p> </div> ^5</sup>See Specifying glibc Version in Cargo Build</a> for techniques.</p> </div> ^3</sup>Cargo's [env]</code> table only supports exact environment variable names (no per-target variants). See Cargo Configuration Reference</a>.</p> </div> ^4</sup>See the pkg-config crate documentation</a> for supported cross-compilation environment variables.</p> </div> `diesel-rs` ORM - typed SQL `sum(BigInt)` invocations 2025-07-15T00:00:00+00:00 Using diesel-rs</code> 2.2.x: sum()</code> with AS</code> and Type Handling (Version Control Example) Introduction diesel-rs</code> is a powerful ORM for Rust, enabling safe and efficient database interactions. In version 2.2.x, summing values with an AS</code> alias requires careful handling of SQL types and Diesel’s type system. This post explains how to use sum(_)</code> with AS</code> via raw SQL and the Diesel DSL, using a version control system</strong> as inspiration for the schema and tables.</p> Problem Statement When using SUM(column) AS alias</code> in SQL, you must alias the result to map it to a Rust struct. Diesel’s type system, however, can complicate this for BigInt</code> columns due to the Foldable</code> trait’s dependency on Numeric</code> types.</p> Let's exercise using a fictive VCS database example:</p> Schema Setup Tables Overview Here's a simplified version control schema:</p> commits</strong>: id, repository_id, author_id, message, timestamp</li> files</strong>: id, repository_id, name, path</li> file_versions</strong>: id, file_id, commit_id, content_hash, content_size</li> repositories</strong>: id, name, description</li> users</strong>: id, username, email</li> </ul> Setup Instructions To generate the schema using diesel</code> with SQLite, omitting any migrations:</p> --</span> Create repositories table </span></span>--</span> Stores information about each repository </span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>repositories</span></span> ( </span> id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT, </span> name TEXT</span> NOT</span> NULL</span>, </span> description TEXT</span> </span>); </span> </span>--</span> Create users table </span></span>--</span> Stores information about users (authors of commits) </span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>users</span></span> ( </span> id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT, </span> username TEXT</span> NOT</span> NULL</span> UNIQUE, </span> email TEXT</span> NOT</span> NULL</span> UNIQUE </span>); </span> </span>--</span> Create commits table </span></span>--</span> Records each commit made in a repository </span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>commits</span></span> ( </span> id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT, </span> repository_id INTEGER</span> NOT</span> NULL</span>, </span> author_id INTEGER</span> NOT</span> NULL</span>, </span> message TEXT</span> NOT</span> NULL</span>, </span> timestamp</span> DATETIME</span> DEFAULT</span> CURRENT_TIMESTAMP</span>, </span> FOREIGN KEY</span> (repository_id) REFERENCES</span> repositories(id), </span> FOREIGN KEY</span> (author_id) REFERENCES</span> users(id) </span>); </span> </span>--</span> Create files table </span></span>--</span> Stores information about files in a repository </span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>files</span></span> ( </span> id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT, </span> repository_id INTEGER</span> NOT</span> NULL</span>, </span> name TEXT</span> NOT</span> NULL</span>, </span> path</span> TEXT</span> NOT</span> NULL</span>, </span> FOREIGN KEY</span> (repository_id) REFERENCES</span> repositories(id) </span>); </span> </span>--</span> Create file_versions table </span></span>--</span> Tracks changes to files over time (e.g., each version of a file in a commit) </span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>file_versions</span></span> ( </span> id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT, </span> file_id INTEGER</span> NOT</span> NULL</span>, </span> commit_id INTEGER</span> NOT</span> NULL</span>, </span> content_hash TEXT</span> NOT</span> NULL</span>, </span> content_size INTEGER</span> NOT</span> NULL</span>, </span> FOREIGN KEY</span> (file_id) REFERENCES</span> files(id), </span> FOREIGN KEY</span> (commit_id) REFERENCES</span> commits(id) </span>); </span></code></pre> cargo</span></span> binstall diesel_cli</span> </span>sqlite3</span></span> -</span>init</span> ./src/db/migrations/001-init.sql ephemeral_setup.db "</span>"</span></span></span> </span>diesel</span></span> setup --</span>database-url</span>=</span>./ephemeral_setup.db</span> </span>diesel</span></span> print-schema ></span> src/db/schema.rs</span> </span></code></pre> Example Schema File table!</span> {</span> </span></span> commits (</span>id</span>)</span></span> {</span> </span></span></span> id -></span> Integer</span>,</span> </span></span></span> repository_id -></span> Integer</span>,</span> </span></span></span> author_id -></span> Integer</span>,</span> </span></span></span> message -></span> Text</span>,</span> </span></span></span> timestamp -></span> DateTime</span>,</span> </span></span></span> </span>}</span></span> </span></span></span>}</span></span> </span> </span>table!</span> {</span> </span></span> file_versions (</span>id</span>)</span></span> {</span> </span></span></span> id -></span> Integer</span>,</span> </span></span></span> file_id -></span> Integer</span>,</span> </span></span></span> commit_id -></span> Integer</span>,</span> </span></span></span> content_hash -></span> Text</span>,</span> </span></span></span> content_size -></span> BigInt</span>,</span> </span></span></span> </span>}</span></span> </span></span></span>}</span></span> </span> </span>table!</span> {</span> </span></span> repositories (</span>id</span>)</span></span> {</span> </span></span></span> id -></span> Integer</span>,</span> </span></span></span> name -></span> Text</span>,</span> </span></span></span> description -></span> Text</span>,</span> </span></span></span> </span>}</span></span> </span></span></span>}</span></span> </span></code></pre> Problem: Summing File Sizes Let’s say we want to sum the total content size</strong> of all files in a specific repository.</p> Raw SQL Approach Use sql_query()</code> for direct control over SQL and aliasing.</p> #</span>[</span>derive</span>(</span></span></span>Debug,</span> PartialEq,</span> Clone</span></span>)</span></span></span>]</span></span> </span>struct</span> </span>TotalSize</span> </span>{</span> </span></span></span> total_size</span>:</span> i64</span>, </span></span></span></span>}</span></span></span> </span> </span>impl</span> </span>QueryableByName<</span>Sqlite></span></span> for</span></span> TotalSize</span> </span>{</span> </span></span></span> fn</span> </span>build</span></span><</span>'a</span>></span></span>(</span>row</span>:</span> &</span>impl NamedRow<</span>'a</span>, Sqlite></span></span></span>)</span></span></span></span> -></span> diesel::</span></span>deserialize::</span></span>Result</span><</span>Self</span>></span></span></span> </span>{</span> </span></span></span></span></span> let</span> total_size =</span> NamedRow::</span></span><</span>'a</span>, Sqlite></span></span>::</span></span>get::</span></span><</span>BigInt, i64</span>></span></span>(</span>row,</span> "</span>total_size"</span></span></span>)</span></span>?</span>;</span> </span></span></span></span></span> Ok</span>(</span>Self</span> {</span> total_size </span>}</span></span></span>)</span></span> </span></span></span></span></span> </span>}</span></span></span> </span></span></span></span>}</span></span></span> </span> </span>let</span> repo_id =</span> 1</span>;</span> </span>let</span> result =</span> diesel::</span></span>sql_query(</span> </span></span> "</span>SELECT SUM(content_size) AS total_size FROM file_versions </span></span></span> JOIN commits ON file_versions.commit_id = commits.id </span></span></span> JOIN repositories ON commits.repository_id = repositories.id </span></span></span> WHERE repositories.id = ?"</span></span>,</span> </span></span></span>)</span></span> </span>.</span>bind::</span></span><</span>Integer, _</span>></span></span>(</span>&</span>repo_id</span>)</span></span> </span>.</span>get_result::</span></span><</span>Option</span><</span>TotalSize></span></span>></span></span>(</span>conn</span>)</span></span> </span>.</span>optional</span>(</span></span>)</span></span>?</span> </span>.</span>flatten</span>(</span></span>)</span></span>;</span> </span> </span>dbg!</span>(</span>result</span>)</span></span>;</span> </span></code></pre> Why this works:</strong></p> Uses raw SQL with AS</code> to alias the result.</li> QueryableByName</code> maps the alias "total_size"</code> to the struct field.</li> Binds parameters safely, avoiding type system conflicts.</li> </ul> Solution 2: Diesel DSL with BigDecimal</code> Using sum()</code> with AS</code> in Diesel requires type annotations and custom types.</p> use</span> diesel::</span></span>dsl::</span></span>sum;</span> </span> </span>let</span> maybe_total_size =</span> SelectDsl::</span></span>select(</span> </span></span> schema::</span></span>file_versions::</span></span>table,</span> </span></span> sum::</span></span><</span>BigInt, _</span>></span></span>(</span>schema::</span></span>file_versions::</span></span>content_size</span>)</span></span>,</span> </span></span></span>)</span></span> </span>.</span>inner_join</span>(</span>schema::</span></span>commits::</span></span>table.</span>on</span>(</span>schema::</span></span>file_versions::</span></span>commit_id.</span>eq</span>(</span>schema::</span></span>commits::</span></span>id</span>)</span></span></span>)</span></span></span>)</span></span> </span>.</span>inner_join</span>(</span>schema::</span></span>repositories::</span></span>table.</span>on</span>(</span>schema::</span></span>commits::</span></span>repository_id.</span>eq</span>(</span>schema::</span></span>repositories::</span></span>id</span>)</span></span></span>)</span></span></span>)</span></span> </span>.</span>filter</span>(</span>schema::</span></span>repositories::</span></span>id.</span>eq</span>(</span>repo_id</span>)</span></span></span>)</span></span> </span>.</span>get_result::</span></span><</span>Option</span><</span>BigIntSum></span></span>></span></span>(</span>conn</span>)</span></span> </span>.</span>optional</span>(</span></span>)</span></span>?</span> </span>.</span>flatten</span>(</span></span>)</span></span>;</span> </span></code></pre> Note:</strong> If BigInt</code> is not supported, you may need to use BigDecimal</code> for more flexibility with large values.</p> Final Notes Using diesel-rs</code> with a version control schema demonstrates how ORMs can be applied in a common, real-world scenario</strong>. The example shows how to:</p> Set up a schema with multiple tables.</li> Query using both raw SQL and the Diesel DSL.</li> Sum values with type-safe handling.</li> </ul> ORMs like Diesel are excellent for productivity and safety</strong> in most applications, but they are not a one-size-fits-all solution. Use them when they align with your project’s needs, and be prepared to fall back to raw SQL when performance, flexibility, or database-specific features are required.</p> From `Containerfile` via `podman` to `fly.io` 2025-07-15T00:00:00+00:00 How to Deploy a Pre-Built Container to fly.io Using Podman</strong></p> Preface</strong> Many of my services are effectively Rust binaries with a shallow Containerfile. I oftentimes have the container image already ready to go locally and do not want to have an external build pass re-do the same work again. Consequently, I was looking for a way to deploy container images a while back and found fly.io</code>, which served and serves the purpose well. A quick, updated document on how to do it.</p> Overview</strong> This guide shows how to deploy a pre-built container to fly.io</strong> using Podman</strong>, bypassing Docker. It assumes you already have a container image with digest 7a7bb109</code> and an existing app named buxbunny</code>.</p> Steps</strong> 1. Tag Your Local Image</strong> Assign the image to the fly.io registry:</p> podman</span></span> tag 7a7bb109 registry.fly.io/buxbunny:latest </span> </span></code></pre> 2. Create a Deploy Token and Log In</strong> Generate a deploy token and use it to authenticate with Podman in one step:</p> flyctl</span></span> tokens create deploy</span> \|</span> podman</span></span> login -</span>u</span> x --</span>password-stdin</span> registry.fly.io/buxbunny </span> </span></code></pre> 3. Push the Image</strong> Upload the tagged image to the fly.io registry:</p> podman</span></span> push registry.fly.io/buxbunny:latest </span> </span></code></pre> 4. Deploy Using fly.toml</code></strong> Update fly.toml</code> to use the pre-built image:</p> #</span>..</span> </span> </span>[</span>build</span></span>]</span> </span> </span>image</span></span> =</span> "</span>registry.fly.io/buxbunny:latest"</span></span> </span> </span> </span>#</span>..</span> </span></code></pre> Then deploy:</p> flyctl</span></span> deploy --</span>app</span> buxbunny </span> </span></code></pre> Key Notes</strong> Ensure the registry URL and app name in fly.toml</code> match your setup</li> No Dockerfile</code> or build context is required when using the image</code> field</li> </ul> Original source: https://community.fly.io/t/howto-use-podman-instead-of-docker-for-local-builds-and-uploading-container-images/542</a></p> Stumbling blocks - the Quectel EM05-G LTE Modem under Fedora 39 2024-05-10T00:00:00+00:00 An attempt to collect all scattered information, yielding a successful connection to a LTE network using the Quectel EM05-G</code> as found in the Lenovo T14s Gen 3 AMD</code>. The below is not a one-size-fits-all solution, but a key-value, problem-solution approach with a defined goal.</p> Open 2023-11-01T00:00:00+00:00 If you're in need for a rust focused backend, embedded, protocols, applied-cryptography, code generators, GPUs or accelerators, transpilers or compilers, I might be just the right engineer for the job.</p>

glibc Symbol Versioning — what it is, how to control it, and how to verify it

2026-02-10T00:00:00+00:00

glibc Symbol Versioning

You've cross-compiled your binary, shipped it to a server, and get:</p>

./myapp: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./myapp)
</span></code></pre>
The binary is the right architecture. The target has glibc. But it's the wrong version</em>. The runtime linker refuses to load the binary because it references symbols tagged with a glibc version newer than what's installed.</p>
Understanding why</em> this happens — and what you can do about it — requires understanding ELF symbol versioning.</p>
This post picks up where Cross-Compiling Rust for aarch64 on Fedora</a> left off (specifically Issue 10: Binary Compatibility) and goes deep on the versioning mechanism itself.</p>
What is Symbol Versioning?
    Traditional shared libraries have a single namespace: when you call memcpy</code>, the dynamic linker finds memcpy</code> in libc.so.6</code> and you're done. But what happens when the semantics</em> of memcpy</code> change between library versions?</p>
glibc solved this with ELF symbol versioning</strong> (introduced in glibc 2.1, ~1999). Every exported symbol carries a version tag. When you compile against glibc 2.38, your binary records that it needs, say, memcpy@GLIBC_2.14</code> — the version of memcpy</code> whose ABI was introduced in glibc 2.14.</p>
The mechanism uses three ELF sections:</p>

.gnu.version</code></strong> — per-symbol version index table (maps each dynamic symbol to a version)</li>
.gnu.version_r</code></strong> — version requirements</em> (lists which versioned interfaces this binary needs)</li>
.gnu.version_d</code></strong> — version definitions</em> (used by libraries to define</em> versions they provide)</li>
</ul>
When the dynamic linker (ld-linux.so</code>) loads your binary, it checks .gnu.version_r</code> against what the loaded libc.so.6</code> defines in .gnu.version_d</code>. If any required version is missing, you get the error above.</p>
Why Not Just Use sonames?
    Sonames (libc.so.6</code>) tell you the major</em> ABI version. Symbol versioning is finer-grained — it tracks individual function interfaces within</em> the same soname. glibc has been libc.so.6</code> since glibc 2.0, yet the library has evolved enormously. Without symbol versioning, glibc couldn't change any function signature or semantic without bumping to libc.so.7</code> and breaking every binary on the system.</p>
Symbol versioning lets multiple implementations of the same function coexist in a single library. Old binaries call memcpy@GLIBC_2.2.5</code>, new binaries call memcpy@GLIBC_2.14</code> — same library file, different implementations dispatched by version tag.</p>
Inspecting Symbol Versions
    Finding the Maximum Required glibc Version
    The maximum glibc version tag in your binary determines the minimum glibc your target system must have.</p>
#</span></span> one-liner: extract the highest required GLIBC version</span>
</span></span>objdump</span></span> -</span>T</span> ./myapp</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_\K[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span> |</span> tail</span></span> -</span>1</span></span>
</span></code></pre>
Listing All Required Version Tags
    #</span></span> show every versioned symbol import</span>
</span></span>objdump</span></span> -</span>T</span> ./myapp</span> |</span> grep</span></span> '</span>GLIBC_'</span></span></span>
</span></code></pre>
Example output:</p>
0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) write
</span>0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.34)  __libc_start_main
</span>0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.38)  strlcpy
</span></code></pre>
Here, strlcpy@GLIBC_2.38</code> is what pulls the minimum glibc version up to 2.38.</p>
Using readelf</code> for the Full Picture
    #</span></span> version requirements section — summarizes which libraries and versions are needed</span>
</span></span>readelf</span></span> -</span>V</span> ./myapp</span>
</span></code></pre>
Output contains two sections:</p>

Version symbols</strong> (.gnu.version</code>) — index per dynamic symbol</li>
Version needs</strong> (.gnu.version_r</code>) — aggregated list of required versions per shared library</li>
</ol>
The "Version needs" section is the most useful:</p>
Version needs section '.gnu.version_r' contains 1 entry:
</span> Addr: 0x00000000000004b0  Offset: 0x000004b0  Link: 7 (.dynstr)
</span>  000000: Version: 1  File: libc.so.6  Cnt: 4
</span>  0x0010:   Name: GLIBC_2.38   Flags: none  Version: 5
</span>  0x0020:   Name: GLIBC_2.34   Flags: none  Version: 4
</span>  0x0030:   Name: GLIBC_2.17   Flags: none  Version: 3
</span>  0x0040:   Name: GLIBC_2.2.5  Flags: none  Version: 2
</span></code></pre>
Hunting Down a Specific Version Tag
    When you see GLIBC_2.38</code> and want to know which function</em> caused it:</p>
objdump</span></span> -</span>T</span> ./myapp</span> |</span> grep</span></span> '</span>GLIBC_2.38'</span></span></span>
</span></code></pre>
This tells you exactly which symbol(s) pull in the newest version requirement.</p>
How Binaries Acquire Version Tags
    A binary's glibc version requirements come from compile-time linking</strong>, not from the code you write. When the linker resolves strlcpy</code> against the system's libc.so.6</code>, it records the default version</em> of that symbol as it exists in the library at link time.</p>
glibc marks exactly one version of each symbol as the default (shown with @@</code> in objdump -T</code> output on the library itself):</p>
#</span></span> on the library: @@ means "default version"</span>
</span></span>objdump</span></span> -</span>T</span> /lib64/libc.so.6</span> |</span> grep</span></span> '</span> memcpy'</span></span></span>
</span></code></pre>
00000000000a1f40  w   DF .text  0000000000000032 (GLIBC_2.14)  memcpy
</span></code></pre>
If your code (or any C library call made by your dependencies) references a function whose default version is GLIBC_2.38</code>, your binary will require glibc 2.38.</p>
Where Do the Versions Come From in Rust?
    Rust binaries link to glibc for:</p>

Rust's std</code> runtime</strong> — pthread_*</code>, malloc</code>, mmap</code>, write</code>, etc.</li>
C dependencies</strong> via -sys</code> crates — anything using cc-rs</code>, pkg-config</code>, or cmake</code> to link native libraries</li>
The CRT startup code</strong> — Scrt1.o</code>, crti.o</code> reference __libc_start_main</code> and friends</li>
</ol>
The version tag on __libc_start_main</code> alone often determines your minimum glibc. On Fedora 42 (glibc 2.41), this symbol defaults to GLIBC_2.34</code>.</p>
Strategies to Lower the glibc Requirement
    Strategy 1: Build Against an Older Sysroot
    The simplest approach: if you link against an older glibc, you naturally get older version tags.</p>
#</span></span> install a Fedora 40 (glibc 2.39) sysroot</span>
</span></span>sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc40 \
</span></span></span>         --</span>releasever</span>=</span>40 --</span>forcearch</span>=</span>aarch64 --</span>use-host-config</span> \
</span></span></span>         install glibc-devel gcc libgcc</span>
</span></code></pre>
Or use a container image based on the oldest distro you need to support:</p>
#</span></span> Debian 11 "bullseye" ships glibc 2.31</span>
</span></span>FROM</span></span> debian:bullseye</span>
</span></code></pre>
This is the recommended</strong> approach. The glibc headers and stubs at compile time determine the version tags. Build old → link old → run everywhere that's ≥ old.</p>
Strategy 2: The .symver</code> Directive (C/C++ Only)
    When building against a new glibc but you need to pin specific symbols to older versions, the .symver</code> assembler directive overrides version resolution at link time:</p>
//</span> force the linker to use the GLIBC_2.17 version of clock_gettime
</span></span>__asm__</span>(</span></span></span>"</span>.symver clock_gettime,clock_gettime@GLIBC_2.17"</span></span></span>)</span></span></span>;</span>
</span></code></pre>
Place this before</em> any code that calls clock_gettime</code>. The linker will bind to the GLIBC_2.17</code> version instead of whatever the default is on your build system.</p>
Caveats:</strong></p>

Only works for symbols that actually existed</em> in that older version</li>
If glibc changed the function's semantics between versions, you get the old behavior — make sure that's what you want</li>
Must be applied per symbol</em></li>
Doesn't work directly from Rust (but can be used in C shims linked via cc-rs</code>)</li>
</ul>
A working example is in the demo repository</a>.</p>
Strategy 3: Linker Version Script
    Instead of pinning individual symbols, you can use a linker version script to restrict all symbol resolutions:</p>
/* glibc_2_17.ver — restrict to glibc ≤ 2.17 */
</span>GLIBC_2.17 {
</span>    *;
</span>};
</span></code></pre>
Pass it to the linker:</p>
gcc</span></span> -</span>o</span> myapp myapp.c -</span>Wl</span>,--version-script=glibc_2_17.ver</span>
</span></code></pre>
Or in .cargo/config.toml</code>:</p>
[</span>build</span></span>]</span>
</span>rustflags</span></span> =</span> [</span>"</span>-C"</span></span>,</span> "</span>link-arg=-Wl,--version-script=glibc_2_17.ver"</span></span>]</span>
</span></code></pre>
Limitations:</strong> this can cause linker errors if your binary uses symbols that didn't exist in the specified version. You may need to combine this with .symver</code> overrides or remove the offending code.</p>
Strategy 4: Use .symver</code> via a C Wrapper (for Rust)
    Since Rust doesn't have inline assembly that can emit .symver</code>, the workaround is a small C shim:</p>
/*</span> compat.c — pin problematic symbols to older glibc versions */</span></span>
</span>#include</span> <</span>features.h></span></span>
</span></span>
</span>/*</span> pin fcntl to GLIBC_2.2.5 (glibc 2.28+ defaults to GLIBC_2.28) */</span></span>
</span>__asm__</span>(</span></span></span>"</span>.symver fcntl,fcntl@GLIBC_2.2.5"</span></span></span>)</span></span></span>;</span>
</span>
</span>/*</span> pin reallocarray to GLIBC_2.26 if it exists, or provide a fallback */</span></span>
</span>__asm__</span>(</span></span></span>"</span>.symver reallocarray,reallocarray@GLIBC_2.26"</span></span></span>)</span></span></span>;</span>
</span></code></pre>
Then in your build.rs</code>:</p>
fn</span> </span>main</span></span>(</span></span>)</span></span></span></span> </span>{</span>
</span></span></span>    cc::</span></span>Build::</span></span>new(</span></span>)</span></span>
</span></span></span>        .</span>file</span>(</span>"</span>compat.c"</span></span></span>)</span></span>
</span></span></span>        .</span>compile</span>(</span>"</span>compat"</span></span></span>)</span></span>;</span>
</span></span></span></span>}</span></span></span>
</span></code></pre>
The pinned versions from the C translation unit affect the final binary's symbol table.</p>
A Practical Example
    The demo repository</a> contains a complete, working example of a C program that:</p>

Uses strlcpy</code> (introduced in glibc 2.38) and clock_gettime</code> (interface changed in glibc 2.17 → 2.34)</li>
Uses .symver</code> to pin symbols to older versions</li>
Provides a comparison: build with and without version pinning</li>
</ol>
Building the Demo
    git</span></span> clone https://github.com/konifay/blogpost-demos.git</span>
</span>cd</span></span> blogpost-demos/2026-0002-glibc-symbol-versioning</span>
</span>
</span>#</span></span> build without version pinning (links to whatever your system glibc provides)</span>
</span></span>make</span></span> unpinned</span>
</span>
</span>#</span></span> inspect: will show your system's default (e.g. GLIBC_2.38 for strlcpy)</span>
</span></span>make</span></span> check-unpinned</span>
</span>
</span>#</span></span> build WITH version pinning</span>
</span></span>make</span></span> pinned</span>
</span>
</span>#</span></span> inspect: strlcpy replaced with manual impl, clock_gettime pinned to 2.17</span>
</span></span>make</span></span> check-pinned</span>
</span></code></pre>
Verification Checklist
    After building, always verify:</p>
1. Maximum glibc Version Required
    objdump</span></span> -</span>T</span> ./myapp</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_\K[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span> |</span> tail</span></span> -</span>1</span></span>
</span></code></pre>
2. No Unexpected Version Tags
    #</span></span> list all unique GLIBC versions required</span>
</span></span>objdump</span></span> -</span>T</span> ./myapp</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_\K[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span>
</span></code></pre>
Compare against the glibc version on your target system:</p>
#</span></span> on the target system</span>
</span></span>/lib64/libc.so.6</span></span> |</span> head</span></span> -</span>1</span></span>
</span>#</span></span> or: ldd --version | head -1</span>
</span></span></code></pre>
3. Full Version Requirements Summary
    readelf</span></span> -</span>V</span> ./myapp 2</span>></span>/dev/null</span> |</span> grep</span></span> -</span>A100</span> '</span>Version needs'</span></span></span>
</span></code></pre>
4. Test on the Target
    The ultimate verification. If possible, run on a system (or container) with the exact glibc version you're targeting:</p>
#</span></span> example: test against glibc 2.31 using Debian Bullseye</span>
</span></span>podman</span></span> run --</span>rm</span> -</span>v</span> ./myapp:/myapp:z debian:bullseye /myapp</span>
</span></code></pre>
Quick Reference Script
    #</span></span>!/bin/bash</span>
</span></span>#</span></span> check-glibc-compat.sh — verify glibc version requirements of a binary</span>
</span></span>BINARY</span>=</span>"</span>$</span>{</span></span>1</span></span>:?</span></span>Usage: $</span>0</span></span> <binary></span>}</span></span>"</span></span></span>
</span>
</span>echo</span></span> "</span>=== glibc version requirements for: $</span>BINARY</span></span> ==="</span></span></span>
</span>echo</span></span> "</span>"</span></span></span>
</span>echo</span></span> "</span>Required GLIBC versions (ascending):"</span></span></span>
</span>objdump</span></span> -</span>T</span> "</span>$</span>BINARY</span></span>"</span></span> 2</span>></span>/dev/null</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_\K[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span>
</span>echo</span></span> "</span>"</span></span></span>
</span>echo</span></span> "</span>Maximum required: GLIBC_$</span>(</span>objdump</span></span> -</span>T</span> "</span>$</span>BINARY</span></span>"</span></span> 2</span>></span>/dev/null</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_\K[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span> |</span> tail</span></span> -</span>1</span></span>)</span></span>"</span></span></span>
</span>echo</span></span> "</span>"</span></span></span>
</span>echo</span></span> "</span>Symbols by version:"</span></span></span>
</span>for</span> ver in</span> $</span>(</span>objdump</span></span> -</span>T</span> "</span>$</span>BINARY</span></span>"</span></span> 2</span>></span>/dev/null</span> |</span> grep</span></span> -</span>oP</span> '</span>GLIBC_[0-9.]+'</span></span></span> |</span> sort</span></span> -</span>Vu</span></span>)</span></span></span>;</span> do</span>
</span>    count</span>=</span>$</span>(</span>objdump</span></span> -</span>T</span> "</span>$</span>BINARY</span></span>"</span></span> 2</span>></span>/dev/null</span> |</span> grep</span></span> -</span>c</span> "</span>$</span>ver</span></span>"</span></span></span>)</span></span></span>
</span>    echo</span></span> "</span>  $</span>ver</span></span>: $</span>count</span></span> symbol(s)"</span></span></span>
</span>done</span>
</span></code></pre>
Common Pitfalls
    __libc_start_main@GLIBC_2.34</code>
    On glibc ≥ 2.34, the CRT startup code (Scrt1.o</code>) references __libc_start_main@GLIBC_2.34</code>. There's no way to .symver</code> this away — it's baked into the object file the linker pulls from the sysroot. The fix is to use a sysroot from an older glibc (Strategy 1).</p>
Transitive Dependencies
    Even if your</em> code uses no new symbols, your dependencies might. A C library you link against may have been compiled on a newer system. Use objdump -T</code> on individual .so</code> files to trace which library introduces the offending version.</p>
strlcpy</code> / strlcat</code> (glibc 2.38)
    These were added to glibc in 2.38 after decades of debate. Some C code started using them immediately. If you link against a library that calls strlcpy</code>, your binary inherits the GLIBC_2.38</code> requirement. Options:</p>

Provide your own strlcpy</code> implementation that the linker picks up first</li>
Build the offending library from source against an older sysroot</li>
Use .symver</code> to point at a compat shim</li>
</ul>
Rust std</code> Baseline
    Rust's tier-1 x86_64-unknown-linux-gnu</code> target requires glibc ≥ 2.17 as of Rust 1.64+. However, if you build on a system with glibc 2.41, the linked</em> binary may require 2.34+ due to __libc_start_main</code>. Always check the actual binary, not just the Rust docs.</p>
tl;dr
    Goal</th> Method</th></tr></thead>

Know your binary's glibc requirement</td> objdump -T binary | grep GLIBC</code></td></tr>
Lower the requirement broadly</td> Build against an older sysroot / container</td></tr>
Pin specific C symbols to old versions</td> .symver</code> directive in C code</td></tr>
Pin symbols from Rust</td> C shim with .symver</code> via cc-rs</code></td></tr>
Restrict all symbols via linker</td> --version-script</code> with version cap</td></tr>
Verify on target</td> Run in a container with the target glibc</td></tr>
</tbody></table>
The safest, most predictable approach is building against the oldest glibc you need to support</strong>. The .symver</code> trick is useful for surgical fixes when you can't change your entire build environment.</p>
A working demo with all techniques is at https://github.com/konifay/blogpost-demos/tree/main/2026-0002-glibc-symbol-versioning</a>.</p>
Resources
    
glibc FAQ: Symbol Versioning</a></li>
ELF Symbol Versioning — Ulrich Drepper</a></li>
Cross-Compiling Rust for aarch64 on Fedora</a></li>
Specifying glibc Version in Cargo Build</a></li>
GNU ld --version-script</code> Documentation</a></li>
</ul>


Cross-Compiling a rust app for target aarch64 on host x86_64 using Fedora 42
2026-02-05T00:00:00+00:00
Cross-Compiling Rust for aarch64 on Fedora x86_64
    Introduction
    Over the last several years, the cloud has shifted from being dominated by x86_64 and sprinkle of PowerPC based systems to including a significant share of aarch64 across all major hyperscalers.
As a result, cross-compiling Rust projects for aarch64 on a Fedora x86_64 host — especially with real-world native library dependencies — is now more common.</p>
Problem Statement
    With a heterogeneous system it becomes harder to quickly patch and upload a binary. Best case, your CI infra is also integrated with your CD infra and allows
blue green testing, i.e. of an odd SIGSEGV such that you can test hypothesis quickly without much pain.
However, many small to medium size teams do not have that luxury of a sophisticated deployment pipeline.</p>
There are still options left, like compiling on a remote machine, compiling in qemu, all with their particular set of tradeoffs.</p>
The most popular being musl, but musl suffers from a mediocre integration into buildtools, always failing in unexpected ways, and
being difficult to get right consistently with dependencies that assume glibc presence.</p>
For the immediate and fast cycle times, I do cross compile locally, and that's what we'll delve into.</p>
Definition of Cross Compiling
    Cross compiling means building a binary on one machine (the host</strong>) that is intended to run on another machine or environment (the target</strong>).
The difference can be CPU architecture (x86_64 vs aarch64), operating system (Linux vs Windows), or even libc (glibc vs musl).</p>

Host</strong>: the system doing the compilation (your local workstation)</li>
Target</strong>: the system where the binary will run (the server/device)</li>
Architecture</strong>: the CPU instruction set (x86_64, aarch64, etc.)</li>
</ul>
In short: you compile on host</em> for a target</em> with a different architecture</em>, and that implies you need the right toolchain, headers, and libraries for the given target.</p>
First steps
    Install the cross-compilation toolchain:</p>
#</span></span> Add Rust aarch64 target</span>
</span></span>rustup</span></span> target add aarch64-unknown-linux-gnu</span>
</span>
</span>#</span></span> Install aarch64 GCC cross-compiler</span>
</span></span>sudo</span></span> dnf install gcc-aarch64-linux-gnu</span>
</span></code></pre>
See the Rust Cross-Compilation Guide</a> for more details on adding targets.</p>
Now, if you thought</p>
cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu</span>
</span></code></pre>
would be good to go, you are likely to be disappointed. It will work for a pure rust project.
But reality doesn't quite comply.</p>
Example Project
    In the following we shall assume our example has dependencies - either dynamically linked or statically linked -
for which packages exist in the target specific distribution repositories, i.e. libsqlite3-devel.aarch64</code> exists
in fedora:42</code>.
We'll assume cargo</code> as our build tool of choice.</p>
Solution: Sysroot Configuration
    What is Sysroot?
    It's really just a minimal filesystem for the target architecture. It contains a basic directory structure.</p>

Location</strong>: /usr/aarch64-redhat-linux/sys-root/fc42/</code></li>
Structure</strong>: Mirrors a typical Linux root with /usr/lib64</code>, /usr/include</code></li>
Purpose</strong>: Provides headers and libraries for the target architecture</li>
</ul>
It does not</em> provide you the ability to execute aarch64 binaries on x86_64, for that you need an emulator like qemu.</p>
How it's done
    When you specify --sysroot</code>, the compiler/linker searches there instead of /usr</code> on your host system.</p>
Fedora provides a basic sysroot package for aarch64, and for a few others:</p>
sysroot-aarch64-fc42-glibc.noarch	Sysroot package for glibc, aarch64 architecture
</span>sysroot-i386-fc42-glibc.noarch	Sysroot package for glibc, i386 architecture
</span>sysroot-ppc64le-fc42-glibc.noarch	Sysroot package for glibc, ppc64le architecture
</span>sysroot-s390x-fc42-glibc.noarch	Sysroot package for glibc, s390x architecture
</span>sysroot-x86_64-fc42-glibc.noarch	Sysroot package for glibc, x86_64 architecture
</span></code></pre>
sudo</span></span> dnf install sysroot-aarch64-fc42-glibc.noarch</span>
</span></code></pre>
It contains a directory, just like a root-filesystem, but nothing can be executed since host and target differ in architecture.</p>
Use dnf --installroot</code> to populate it with aarch64 packages1</a></sup>:</p>
sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \
</span></span></span>         --</span>releasever</span>=</span>42 \
</span></span></span>         --</span>forcearch</span>=</span>aarch64 \
</span></span></span>         --</span>use-host-config</span> \
</span></span></span>         install sqlite-devel libgcc glibc-devel gcc</span>
</span>
</span>#</span></span> BUG: Create development symlink for libgcc_s.so since it's missing in fedora:42</span>
</span></span>cd</span></span> /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64</span>
</span>sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 libgcc_s.so</span>
</span>cd</span></span> -</span>
</span></code></pre>
Key flags:</strong></p>

--installroot</code>: Specifies the target root directory</li>
--releasever</code>: Matches your Fedora version (42 in this example)</li>
--forcearch</code>: Forces installation of aarch64 packages</li>
--use-host-config</code>: Uses your host's repository configuration - which works as long as your /etc/yum.repos.d/*.repo</code> files are parameterized across architecture</li>
</ul>
With the sysroot now in place, we need to ensure it's being picked up by rustc</code> as well as any gcc</code>/clang</code>/clang++</code> invocations
as well as the linker.</p>
For that we must provide the paths to the respective invocations via cargo.</p>
Cargo Configuration
    Create or update .cargo/config.toml</code>2</a></sup> in your project or globally in ~/.cargo/config.toml</code>:</p>
[</span>target</span>.</span>aarch64-unknown-linux-gnu</span></span>]</span>
</span>#</span> you can skip `linker = ` if you're using `mold`[^3]</span>
</span>linker</span></span> =</span> "</span>/usr/bin/aarch64-linux-gnu-gcc"</span></span>
</span>rustflags</span></span> =</span> [</span>"</span>-C"</span></span>,</span> "</span>link-arg=--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>]</span>
</span>
</span>#</span> add the target specific sysroot flags for usage in `cc-rs`</span>
</span>[</span>env</span></span>]</span>
</span>CFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include"</span></span>
</span>CXXFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++/15 -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++ -I/usr/aarch64-redhat-linux/sys-root/fc42/usr/include/c++/15/aarch64-redhat-linux"</span></span>
</span>LDFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>PKG_CONFIG_SYSROOT_DIR</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>PKG_CONFIG_PATH</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/pkgconfig:/usr/aarch64-redhat-linux/sys-root/fc42/usr/share/pkgconfig"</span></span>
</span>PKG_CONFIG_ALLOW_CROSS</span></span> =</span> "</span>1"</span></span>
</span></code></pre>
Note: include paths are still absolute</em> to the host filesystem, not relative to the sysroot.
cc-rs honors target-suffixed env vars like CFLAGS_<target></code> or CFLAGS_<target_with_underscores></code>, so the example uses the underscore form to scope flags to aarch64 only.
Cargo .cargo/config.toml</code> does not support target-specific env vars in [env]</code>, so the vars must be named with the target suffix themselves.3</a></sup></p>
Why this is needed:</strong></p>

The linker needs --sysroot</code> to find C runtime objects for the target architecture (Scrt1.o</code>, crti.o</code>, crtn.o</code>)</li>
C/C++ compilation (from build scripts via i.e. cc-rs</code>) needs sysroot for various standard headers and linking to target architecture libraries

Without these flags, the compiler/linker searches the host system and finds x86_64 libraries</li>
</ul>
</li>
</ul>
Building
    As per usual</p>
cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu --</span>release</span></span>
</span></code></pre>
Container-Based Cross-Compilation
    If you don't use Fedora as your host OS, or want a somewhat reproducible build environment, use a container:</p>
Containerfile.cross:</strong></p>
Sets up a compilation environment (rust</code>, cargo</code>, gcc</code>, ..) as well as the aarch64</code> sysroot within</em> the container itself,
so you'll need to modify it to your specific project needs!</p>
FROM</span> fedora:42</span>
</span>
</span>#</span> Install build dependencies (including C++ cross-compiler and CMake)
</span></span>RUN </span>dnf install -y \
</span>    gcc \
</span>    gcc-c++ \
</span>    gcc-aarch64-linux-gnu \
</span>    gcc-c++-aarch64-linux-gnu \
</span>    sqlite-devel \
</span>    make \
</span>    curl \
</span>    pkg-config \
</span>    clang \
</span>    cmake \
</span>    git \
</span>    && dnf clean all
</span>
</span>#</span> Copy rust-toolchain.toml to read the version
</span></span>COPY</span> rust-toolchain.toml /tmp/rust-toolchain.toml
</span>
</span>#</span> Install Rust using rustup with version from rust-toolchain.toml
</span></span>RUN </span>RUST_VERSION=$(grep '</span>^channel'</span></span> /tmp/rust-toolchain.toml | awk -F'</span>"'</span></span> '</span>{print $2}'</span></span>) && \
</span>    echo "</span>Installing Rust version: $RUST_VERSION"</span></span> && \
</span>    curl --proto '</span>=https'</span></span> --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain "</span>$RUST_VERSION"</span></span> --profile minimal
</span>ENV </span>PATH="</span>/root/.cargo/bin:${PATH}"</span></span>
</span>
</span>#</span> Set the default toolchain explicitly
</span></span>RUN </span>RUST_VERSION=$(grep '</span>^channel'</span></span> /tmp/rust-toolchain.toml | awk -F'</span>"'</span></span> '</span>{print $2}'</span></span>) && \
</span>    rustup default "</span>$RUST_VERSION"</span></span>
</span>
</span>#</span> Verify rustup is working and add aarch64 target
</span></span>RUN </span>rustup --version && rustup show && rustup target add aarch64-unknown-linux-gnu
</span>
</span>#</span> Setup sysroot with aarch64 dependencies
</span></span>ENV </span>SYSROOT=/usr/aarch64-redhat-linux/sys-root/fc42
</span>RUN </span>dnf --installroot=${SYSROOT} \
</span>    --releasever=42 \
</span>    --forcearch=aarch64 \
</span>    --use-host-config \
</span>    install -y sqlite-devel libgcc glibc-devel gcc gcc-c++ libstdc++-devel openssl-devel pkgconf-pkg-config \
</span>    && dnf clean all
</span>
</span>#</span> Verify pkg-config files exist
</span></span>RUN </span>ls -la ${SYSROOT}/usr/lib64/pkgconfig/openssl.pc
</span>
</span>#</span> Create libgcc_s.so symlink (linker expects unversioned name)
</span></span>RUN </span>ln -sf libgcc_s.so.1 ${SYSROOT}/usr/lib64/libgcc_s.so
</span>
</span>#</span> Create libstdc++.so symlink (CMake needs this for linking)
</span></span>RUN </span>if [ -f ${SYSROOT}/usr/lib64/libstdc++.so.6 ]; then \
</span>        ln -sf libstdc++.so.6 ${SYSROOT}/usr/lib64/libstdc++.so; \
</span>    fi
</span>
</span>#</span> Set working directory
</span></span>WORKDIR </span>/x
</span>
</span>#</span> Install oq for TOML manipulation
</span></span>RUN </span>/root/.cargo/bin/cargo install oq
</span>
</span>#</span> Ensure cargo is in PATH for CMD
</span></span>ENV </span>PATH="</span>/root/.cargo/bin:${PATH}"</span></span>
</span>
</span>#</span> Copy build entrypoint script
</span></span>COPY</span> build-entrypoint.sh /usr/local/bin/build-entrypoint.sh
</span>RUN </span>chmod +x /usr/local/bin/build-entrypoint.sh
</span>
</span>#</span> Default command - run build script
</span></span>CMD </span>["</span>/usr/local/bin/build-entrypoint.sh"</span></span>]
</span></code></pre>
build-entrypoint.sh:</strong></p>
The actual execution happening inside</em> the container - patching .cargo/config.toml</code>, building your binary.</p>
#</span></span>!/bin/bash</span>
</span></span>set</span></span> -</span>e</span></span>
</span>
</span>SYSROOT</span>=</span>"</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span></span>
</span>#</span></span> Ensure .cargo/config.toml exists</span>
</span></span>mkdir</span></span> -</span>p</span> .cargo</span>
</span>if</span> [</span> !</span> -</span>f</span> .cargo/config.toml ]</span></span>;</span> then</span>
</span>    echo</span></span> "</span>Creating .cargo/config.toml..."</span></span></span>
</span>    touch</span></span> .cargo/config.toml</span>
</span>fi</span>
</span>
</span>#</span></span> Patch .cargo/config.toml</span>
</span></span>echo</span></span> "</span>Patching .cargo/config.toml for cross-compilation..."</span></span></span>
</span>oq</span></span> -</span>i</span> toml -</span>o</span> toml \
</span></span></span>    '</span>.target."aarch64-unknown-linux-gnu".linker = "aarch64-linux-gnu-gcc" |
</span></span></span>     .target."aarch64-unknown-linux-gnu".rustflags = ["-C", "link-arg=--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>"] |
</span></span></span>     .env.CFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.CXXFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.CXXLDFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.LDFLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu = "--sysroot='</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.PKG_CONFIG_SYSROOT_DIR = "'</span></span>$</span>SYSROOT</span></span>'</span>" |
</span></span></span>     .env.PKG_CONFIG_PATH = "'</span></span>$</span>SYSROOT</span></span>'</span>/usr/lib64/pkgconfig:'</span></span>$</span>SYSROOT</span></span>'</span>/usr/share/pkgconfig" |
</span></span></span>     .env.PKG_CONFIG_ALLOW_CROSS = "1"'</span></span> \
</span></span></span>    .cargo/config.toml ></span> .cargo/config.toml.new</span>
</span>
</span>mv</span></span> .cargo/config.toml.new .cargo/config.toml</span>
</span>echo</span></span> "</span>Configuration patched successfully."</span></span></span>
</span>
</span>#</span></span> Build for aarch64</span>
</span></span>echo</span></span> "</span>Building for aarch64-unknown-linux-gnu..."</span></span></span>
</span>cargo</span></span> build --</span>target</span> aarch64-unknown-linux-gnu --</span>release</span></span>
</span></code></pre>
Shell Wrapper:</strong></p>
Convenience helper, build the container using podman</code> and executing the build
while sharing cargo cache and some binaries. If you're on OS X, it will need
adjustments for mapping volumes.</p>

</span>#</span></span> The `crisscross` function expects:</span>
</span></span>#</span></span> - `rust-toolchain.toml` - To determine which Rust version to install</span>
</span></span>#</span></span> - `Containerfile.cross` - Container build instructions</span>
</span></span>#</span></span> - `build-entrypoint.sh` - Script that patches cargo config and runs build</span>
</span></span>function</span> crisscross</span> {</span>
</span></span>    local</span> containerfile</span>=</span>"</span>$</span>{</span></span>1</span></span>:-</span></span>Containerfile.cross</span>}</span></span>"</span></span></span></span>
</span></span>    local</span> image_name</span>=</span>"</span>$</span>{</span></span>2</span></span>:-</span></span>crisscross:aarch64</span>}</span></span>"</span></span></span></span>
</span></span>
</span></span>    podman</span></span> build -</span>t</span> "</span>$</span>image_name</span></span>"</span></span> -</span>f</span> "</span>$</span>containerfile</span></span>"</span></span> .</span> &&</span> \
</span></span></span>    podman</span></span> run --</span>rm</span> -</span>v</span> .:/x:z -</span>v</span> ~</span></span>/.cargo:/root/.cargo:z "</span>$</span>image_name</span></span>"</span></span></span>
</span></span>
</span></span>    echo</span></span> "</span>Build complete!"</span></span></span>
</span></span>    ls</span></span> -</span>lh</span> target/aarch64-unknown-linux-gnu/release 2</span>></span>/dev/null</span> ||</span> echo</span></span> "</span>No binary found"</span></span></span>
</span></span>}</span></span>
</span></code></pre>
Usage: crisscross</code> or crisscross Containerfile.aarch64 my-cross-build-env-setup-containing-sysroot-oci-image:tag</code></p>
A full working demo can be found at https://github.com/konifay/blogpost-demos/tree/main/2026-0001-cross-compile-rust-fedora</a>.</p>
Enjoy!</p>
Resources
    
DNF5 Documentation</a> - See command reference for installroot usage</li>
Rust Cross-Compilation Guide</a></li>
Cargo Configuration Reference</a></li>
pkg-config crate documentation</a></li>
Specifying glibc Version in Cargo Build</a></li>
mold - A Modern Linker</a></li>
sysroot setup for gnome builder</a></li>
</ul>
Troubleshooting Guide
    Below is a comprehensive list of common issues, quirks, and gotchas encountered during cross-compilation.</p>
Issue 1: Missing libgcc_s.so</code>
    Error:</strong></p>
/usr/bin/aarch64-linux-gnu-ld: cannot find -lgcc_s: No such file or directory
</span></code></pre>
Typical offenders:</strong> toolchain/runtime pieces expected by C/C++ build systems and linkers.</p>
Solution:</strong>
The linker looks for libgcc_s.so</code> (without version suffix), but only libgcc_s.so.1</code> exists in the sysroot. Create a symlink:</p>
sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libgcc_s.so</span>
</span></code></pre>
Issue 2: Missing standard headers (e.g., assert.h</code>)
    Error:</strong></p>
c/blake3_impl.h:4:10: fatal error: assert.h: No such file or directory
</span></code></pre>
Typical offenders:</strong> build scripts using cc-rs</code> or C/C++ code in crates like blake3</code> that expect glibc headers.</p>
Solution:</strong>
Install glibc-devel</code> in the sysroot (see the dnf --installroot</code> command above). Ensure CFLAGS</code>/CXXFLAGS</code> include --sysroot</code> so headers resolve correctly.</p>
Issue 3: Missing target libraries (e.g., SQLite, libpq, libgit2)
    Error:</strong></p>
/usr/bin/aarch64-linux-gnu-ld: cannot find -lsqlite3: No such file or directory
</span></code></pre>
Typical offenders:</strong> native -sys</code> crates (sqlite</code>, libpq</code>, libgit2</code>) that expect target-arch -devel</code> packages.</p>
Solution:</strong>
Install the relevant -devel</code> packages in the sysroot via dnf --installroot</code>:</p>
sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \
</span></span></span>    --</span>releasever</span>=</span>42 \
</span></span></span>    --</span>forcearch</span>=</span>aarch64 \
</span></span></span>    --</span>use-host-config</span> \
</span></span></span>    install -</span>y</span> sqlite-devel</span>
</span></code></pre>
Issue 4: OpenSSL Not Found (pkg-config fails)
    Error:</strong></p>
Could not find directory of OpenSSL installation, and this `-sys` crate cannot
</span>proceed without this knowledge. If OpenSSL is installed and this crate had
</span>trouble finding it, you can set the `OPENSSL_DIR` environment variable for the
</span>compilation process.
</span>
</span>Could not find openssl via pkg-config:
</span>pkg-config has not been configured to support cross-compilation.
</span></code></pre>
Typical offenders:</strong> openssl-sys</code> and other crates that rely on pkg-config to locate headers/libs.</p>
Solution:</strong>
Install OpenSSL + pkg-config in the sysroot and configure the cross pkg-config environment:</p>
sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \
</span></span></span>    --</span>releasever</span>=</span>42 \
</span></span></span>    --</span>forcearch</span>=</span>aarch64 \
</span></span></span>    --</span>use-host-config</span> \
</span></span></span>    install -</span>y</span> openssl-devel pkgconf-pkg-config</span>
</span></code></pre>
Add to .cargo/config.toml</code>:</p>
[</span>env</span></span>]</span>
</span>PKG_CONFIG_SYSROOT_DIR</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>PKG_CONFIG_PATH</span></span> =</span> "</span>/usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/pkgconfig:/usr/aarch64-redhat-linux/sys-root/fc42/usr/share/pkgconfig"</span></span>
</span>PKG_CONFIG_ALLOW_CROSS</span></span> =</span> "</span>1"</span></span>
</span></code></pre>
Issue 5: Missing Development Symlinks
    Error:</strong></p>
/usr/bin/aarch64-linux-gnu-ld: cannot find -lfoo: No such file or directory
</span></code></pre>
Where libfoo.so.X</code> exists in the sysroot but libfoo.so</code> symlink is missing.</p>
Typical offenders:</strong> Any crate using cc-rs</code> or direct linking when -devel</code> packages don't create proper symlinks via dnf --installroot</code>.</p>
Root cause:</strong> Development packages typically install versioned libraries (e.g., libfoo.so.1.2.3</code>) and a symlink libfoo.so</code> → libfoo.so.1.2.3</code>. However, when using dnf --installroot</code>, sometimes only the versioned library gets installed without the development symlink. The linker (ld</code>) searches for -lfoo</code> by looking for libfoo.so</code>.</p>
Solution:</strong> Manually create symlinks in the sysroot:</p>
cd</span></span> /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64</span>
</span>#</span></span> Find the actual library version</span>
</span></span>ls</span></span> -</span>la</span> libfoo.so*</span></span>
</span>#</span></span> Create the symlink</span>
</span></span>sudo</span></span> ln -</span>sf</span> libfoo.so.1.2.3 libfoo.so</span>
</span></code></pre>
Common libraries requiring symlinks:</p>

libgcc_s.so.1</code> → libgcc_s.so</code></li>
libstdc++.so.6</code> → libstdc++.so</code></li>
libssl.so.3</code> → libssl.so</code></li>
</ul>
Issue 6: CMake C++ Compiler Test Fails (Missing libstdc++)
    Error:</strong></p>
The C++ compiler "/usr/bin/aarch64-linux-gnu-g++" is not able to compile a simple test program.
</span>/usr/bin/aarch64-linux-gnu-ld: cannot find -lstdc++: No such file or directory
</span></code></pre>
Typical offenders:</strong> CMake-based crates (libz-ng-sys</code>, rocksdb</code>, snappy</code>) that invoke the linker directly and need the C++ runtime.</p>
Solution:</strong>
Install C++ standard library in the sysroot:</p>
sudo</span></span> dnf --</span>installroot</span>=</span>/usr/aarch64-redhat-linux/sys-root/fc42 \
</span></span></span>    --</span>releasever</span>=</span>42 \
</span></span></span>    --</span>forcearch</span>=</span>aarch64 \
</span></span></span>    --</span>use-host-config</span> \
</span></span></span>    install -</span>y</span> gcc-c++ libstdc++-devel</span>
</span></code></pre>
Also ensure linker flags are set:</p>
[</span>env</span></span>]</span>
</span>CXXFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>LDFLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span>CMAKE_EXE_LINKER_FLAGS_aarch64_unknown_linux_gnu</span></span> =</span> "</span>--sysroot=/usr/aarch64-redhat-linux/sys-root/fc42"</span></span>
</span></code></pre>
Critical quirk:</strong> CMake may invoke the linker (aarch64-linux-gnu-ld</code>) directly instead of through the compiler wrapper. The linker needs unversioned .so</code> files (e.g., libstdc++.so</code>, not libstdc++.so.6</code>). Create symlinks:</p>
sudo</span></span> ln -</span>sf</span> libstdc++.so.6 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libstdc++.so</span>
</span>sudo</span></span> ln -</span>sf</span> libgcc_s.so.1 /usr/aarch64-redhat-linux/sys-root/fc42/usr/lib64/libgcc_s.so</span>
</span></code></pre>
Issue 7: CMake Linker Invocation Bypasses Compiler Flags
    CMake often bypasses compiler wrappers and invokes the linker directly. This means CFLAGS</code> and CXXFLAGS</code> may not propagate to the linking stage. You must set:</p>

LDFLAGS_<target></code> - General linker flags</li>
CMAKE_EXE_LINKER_FLAGS_<target></code> - CMake-specific linker flags</li>
CXXLDFLAGS_<target></code> - C++ linker flags (for some build systems)</li>
</ul>
All should include --sysroot=/path/to/sysroot</code>.</p>
Issue 8: Host vs Target Confusion
    Build scripts (build.rs</code>) run on the host</strong> architecture (x86_64), but they may compile code for the target</strong> architecture (aarch64). If a build script requires native tools like clang</code> or cmake</code>, install them on the host system:</p>
dnf</span></span> install -</span>y</span> clang cmake  #</span></span> Host tools</span>
</span></span></span></code></pre>
If the build script compiles C/C++ for the target, ensure cross-compilers are available and CFLAGS_<target></code> is set.</p>
Issue 9: pkg-config Cross-Compilation
    By default, pkg-config</code> searches /usr/lib64/pkgconfig</code> on the host. For cross-compilation:</p>

Set PKG_CONFIG_SYSROOT_DIR</code> to the target sysroot</li>
Set PKG_CONFIG_PATH</code> to <sysroot>/usr/lib64/pkgconfig</code></li>
Set PKG_CONFIG_ALLOW_CROSS=1</code> to bypass sanity checks</li>
</ol>
The pkg-config</code> crate supports target-specific variants of PKG_CONFIG_PATH</code>, PKG_CONFIG_LIBDIR</code>, and PKG_CONFIG_SYSROOT_DIR</code> using suffixes like _aarch64-unknown-linux-gnu</code> or _aarch64_unknown_linux_gnu</code>, plus HOST_</code>/TARGET_</code> prefixes. It only allows cross-compilation when PKG_CONFIG_SYSROOT_DIR</code> or PKG_CONFIG</code> is set; otherwise it refuses to run unless you force it with PKG_CONFIG_ALLOW_CROSS=1</code>.4</a></sup></p>
Without these, openssl-sys</code> and similar crates will fail.</p>
Issue 10: Binary Compatibility
    Binaries built with glibc are not portable</strong> across different glibc versions. If your target system runs Fedora 40 with glibc 2.39, but you build against Fedora 42 with glibc 2.41, the binary may fail with "version `GLIBC_2.41' not found".</p>
Solutions:</strong></p>

Explicitly provide a glibc API version5</a></sup> - glibc provides versioned symbols</li>
Match the Fedora version to your deployment target</li>
Use musl for static binaries (though this has its own challenges)</li>
</ul>
tl;dr
    
Proper sysroot setup with --installroot</code></li>
</ol>

Installing all</strong> native dependencies in the sysroot</li>
</ul>

Cargo configuration to pass sysroot to compiler and linker invocations</li>
Apply specific quirks for your set of libraries</li>
</ol>
The same principles apply to rust/C/C++ cross-compilation.</p>
Footnotes
    ^1</sup>See DNF5 Documentation</a> for more on installroot usage.</p>
</div>
^2</sup>See Cargo Configuration Reference</a> for all available options.</p>
</div>
^6</sup>mold</a> is a fast modern linker with built-in cross-compilation support.</p>
</div>
^5</sup>See Specifying glibc Version in Cargo Build</a> for techniques.</p>
</div>
^3</sup>Cargo's [env]</code> table only supports exact environment variable names (no per-target variants). See Cargo Configuration Reference</a>.</p>
</div>
^4</sup>See the pkg-config crate documentation</a> for supported cross-compilation environment variables.</p>
</div>


`diesel-rs` ORM - typed SQL `sum(BigInt)` invocations
2025-07-15T00:00:00+00:00
Using diesel-rs</code> 2.2.x: sum()</code> with AS</code> and Type Handling (Version Control Example)
    
Introduction
    diesel-rs</code> is a powerful ORM for Rust, enabling safe and efficient database interactions. In version 2.2.x, summing values with an AS</code> alias requires careful handling of SQL types and Diesel’s type system. This post explains how to use sum(_)</code> with AS</code> via raw SQL and the Diesel DSL, using a version control system</strong> as inspiration for the schema and tables.</p>

Problem Statement
    When using SUM(column) AS alias</code> in SQL, you must alias the result to map it to a Rust struct. Diesel’s type system, however, can complicate this for BigInt</code> columns due to the Foldable</code> trait’s dependency on Numeric</code> types.</p>

Let's exercise using a fictive VCS database example:</p>
Schema Setup
    Tables Overview
    Here's a simplified version control schema:</p>

commits</strong>: id, repository_id, author_id, message, timestamp</li>
files</strong>: id, repository_id, name, path</li>
file_versions</strong>: id, file_id, commit_id, content_hash, content_size</li>
repositories</strong>: id, name, description</li>
users</strong>: id, username, email</li>
</ul>
Setup Instructions
    To generate the schema using diesel</code> with SQLite, omitting any migrations:</p>
--</span> Create repositories table
</span></span>--</span> Stores information about each repository
</span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>repositories</span></span> (
</span>    id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT,
</span>    name TEXT</span> NOT</span> NULL</span>,
</span>    description TEXT</span>
</span>);
</span>
</span>--</span> Create users table
</span></span>--</span> Stores information about users (authors of commits)
</span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>users</span></span> (
</span>    id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT,
</span>    username TEXT</span> NOT</span> NULL</span> UNIQUE,
</span>    email TEXT</span> NOT</span> NULL</span> UNIQUE
</span>);
</span>
</span>--</span> Create commits table
</span></span>--</span> Records each commit made in a repository
</span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>commits</span></span> (
</span>    id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT,
</span>    repository_id INTEGER</span> NOT</span> NULL</span>,
</span>    author_id INTEGER</span> NOT</span> NULL</span>,
</span>    message TEXT</span> NOT</span> NULL</span>,
</span>    timestamp</span> DATETIME</span> DEFAULT</span> CURRENT_TIMESTAMP</span>,
</span>    FOREIGN KEY</span> (repository_id) REFERENCES</span> repositories(id),
</span>    FOREIGN KEY</span> (author_id) REFERENCES</span> users(id)
</span>);
</span>
</span>--</span> Create files table
</span></span>--</span> Stores information about files in a repository
</span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>files</span></span> (
</span>    id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT,
</span>    repository_id INTEGER</span> NOT</span> NULL</span>,
</span>    name TEXT</span> NOT</span> NULL</span>,
</span>    path</span> TEXT</span> NOT</span> NULL</span>,
</span>    FOREIGN KEY</span> (repository_id) REFERENCES</span> repositories(id)
</span>);
</span>
</span>--</span> Create file_versions table
</span></span>--</span> Tracks changes to files over time (e.g., each version of a file in a commit)
</span></span>CREATE</span> TABLE</span> </span>IF NOT EXISTS </span>file_versions</span></span> (
</span>    id INTEGER</span> PRIMARY KEY</span> AUTOINCREMENT,
</span>    file_id INTEGER</span> NOT</span> NULL</span>,
</span>    commit_id INTEGER</span> NOT</span> NULL</span>,
</span>    content_hash TEXT</span> NOT</span> NULL</span>,
</span>    content_size INTEGER</span> NOT</span> NULL</span>,
</span>    FOREIGN KEY</span> (file_id) REFERENCES</span> files(id),
</span>    FOREIGN KEY</span> (commit_id) REFERENCES</span> commits(id)
</span>);
</span></code></pre>
cargo</span></span> binstall diesel_cli</span>
</span>sqlite3</span></span> -</span>init</span> ./src/db/migrations/001-init.sql ephemeral_setup.db "</span>"</span></span></span>
</span>diesel</span></span> setup --</span>database-url</span>=</span>./ephemeral_setup.db</span>
</span>diesel</span></span> print-schema ></span> src/db/schema.rs</span>
</span></code></pre>
Example Schema File
    table!</span> {</span>
</span></span>    commits (</span>id</span>)</span></span> {</span>
</span></span></span>        id -></span> Integer</span>,</span>
</span></span></span>        repository_id -></span> Integer</span>,</span>
</span></span></span>        author_id -></span> Integer</span>,</span>
</span></span></span>        message -></span> Text</span>,</span>
</span></span></span>        timestamp -></span> DateTime</span>,</span>
</span></span></span>    </span>}</span></span>
</span></span></span>}</span></span>
</span>
</span>table!</span> {</span>
</span></span>    file_versions (</span>id</span>)</span></span> {</span>
</span></span></span>        id -></span> Integer</span>,</span>
</span></span></span>        file_id -></span> Integer</span>,</span>
</span></span></span>        commit_id -></span> Integer</span>,</span>
</span></span></span>        content_hash -></span> Text</span>,</span>
</span></span></span>        content_size -></span> BigInt</span>,</span>
</span></span></span>    </span>}</span></span>
</span></span></span>}</span></span>
</span>
</span>table!</span> {</span>
</span></span>    repositories (</span>id</span>)</span></span> {</span>
</span></span></span>        id -></span> Integer</span>,</span>
</span></span></span>        name -></span> Text</span>,</span>
</span></span></span>        description -></span> Text</span>,</span>
</span></span></span>    </span>}</span></span>
</span></span></span>}</span></span>
</span></code></pre>

Problem: Summing File Sizes
    Let’s say we want to sum the total content size</strong> of all files in a specific repository.</p>
Raw SQL Approach
    Use sql_query()</code> for direct control over SQL and aliasing.</p>
#</span>[</span>derive</span>(</span></span></span>Debug,</span> PartialEq,</span> Clone</span></span>)</span></span></span>]</span></span>
</span>struct</span> </span>TotalSize</span> </span>{</span>
</span></span></span>    total_size</span>:</span> i64</span>,
</span></span></span></span>}</span></span></span>
</span>
</span>impl</span> </span>QueryableByName<</span>Sqlite></span></span> for</span></span> TotalSize</span> </span>{</span>
</span></span></span>    fn</span> </span>build</span></span><</span>'a</span>></span></span>(</span>row</span>:</span> &</span>impl NamedRow<</span>'a</span>, Sqlite></span></span></span>)</span></span></span></span> -></span> diesel::</span></span>deserialize::</span></span>Result</span><</span>Self</span>></span></span></span> </span>{</span>
</span></span></span></span></span>        let</span> total_size =</span> NamedRow::</span></span><</span>'a</span>, Sqlite></span></span>::</span></span>get::</span></span><</span>BigInt, i64</span>></span></span>(</span>row,</span> "</span>total_size"</span></span></span>)</span></span>?</span>;</span>
</span></span></span></span></span>        Ok</span>(</span>Self</span> {</span> total_size </span>}</span></span></span>)</span></span>
</span></span></span></span></span>    </span>}</span></span></span>
</span></span></span></span>}</span></span></span>
</span>
</span>let</span> repo_id =</span> 1</span>;</span>
</span>let</span> result =</span> diesel::</span></span>sql_query(</span>
</span></span>    "</span>SELECT SUM(content_size) AS total_size FROM file_versions 
</span></span></span>     JOIN commits ON file_versions.commit_id = commits.id 
</span></span></span>     JOIN repositories ON commits.repository_id = repositories.id 
</span></span></span>     WHERE repositories.id = ?"</span></span>,</span>
</span></span></span>)</span></span>
</span>.</span>bind::</span></span><</span>Integer, _</span>></span></span>(</span>&</span>repo_id</span>)</span></span>
</span>.</span>get_result::</span></span><</span>Option</span><</span>TotalSize></span></span>></span></span>(</span>conn</span>)</span></span>
</span>.</span>optional</span>(</span></span>)</span></span>?</span>
</span>.</span>flatten</span>(</span></span>)</span></span>;</span>
</span>
</span>dbg!</span>(</span>result</span>)</span></span>;</span>
</span></code></pre>
Why this works:</strong></p>

Uses raw SQL with AS</code> to alias the result.</li>
QueryableByName</code> maps the alias "total_size"</code> to the struct field.</li>
Binds parameters safely, avoiding type system conflicts.</li>
</ul>

Solution 2: Diesel DSL with BigDecimal</code>
    Using sum()</code> with AS</code> in Diesel requires type annotations and custom types.</p>
use</span> diesel::</span></span>dsl::</span></span>sum;</span>
</span>
</span>let</span> maybe_total_size =</span> SelectDsl::</span></span>select(</span>
</span></span>    schema::</span></span>file_versions::</span></span>table,</span>
</span></span>    sum::</span></span><</span>BigInt, _</span>></span></span>(</span>schema::</span></span>file_versions::</span></span>content_size</span>)</span></span>,</span>
</span></span></span>)</span></span>
</span>.</span>inner_join</span>(</span>schema::</span></span>commits::</span></span>table.</span>on</span>(</span>schema::</span></span>file_versions::</span></span>commit_id.</span>eq</span>(</span>schema::</span></span>commits::</span></span>id</span>)</span></span></span>)</span></span></span>)</span></span>
</span>.</span>inner_join</span>(</span>schema::</span></span>repositories::</span></span>table.</span>on</span>(</span>schema::</span></span>commits::</span></span>repository_id.</span>eq</span>(</span>schema::</span></span>repositories::</span></span>id</span>)</span></span></span>)</span></span></span>)</span></span>
</span>.</span>filter</span>(</span>schema::</span></span>repositories::</span></span>id.</span>eq</span>(</span>repo_id</span>)</span></span></span>)</span></span>
</span>.</span>get_result::</span></span><</span>Option</span><</span>BigIntSum></span></span>></span></span>(</span>conn</span>)</span></span>
</span>.</span>optional</span>(</span></span>)</span></span>?</span>
</span>.</span>flatten</span>(</span></span>)</span></span>;</span>
</span></code></pre>
Note:</strong> If BigInt</code> is not supported, you may need to use BigDecimal</code> for more flexibility with large values.</p>

Final Notes
    Using diesel-rs</code> with a version control schema demonstrates how ORMs can be applied in a common, real-world scenario</strong>. The example shows how to:</p>

Set up a schema with multiple tables.</li>
Query using both raw SQL and the Diesel DSL.</li>
Sum values with type-safe handling.</li>
</ul>
ORMs like Diesel are excellent for productivity and safety</strong> in most applications, but they are not a one-size-fits-all solution. Use them when they align with your project’s needs, and be prepared to fall back to raw SQL when performance, flexibility, or database-specific features are required.</p>


From `Containerfile` via `podman` to `fly.io`
2025-07-15T00:00:00+00:00
How to Deploy a Pre-Built Container to fly.io Using Podman</strong></p>

Preface</strong>
    Many of my services are effectively Rust binaries with a shallow Containerfile. I oftentimes have the container image already ready to go locally and do not want to have an external build pass re-do the same work again. Consequently, I was looking for a way to deploy container images a while back and found fly.io</code>, which served and serves the purpose well. A quick, updated document on how to do it.</p>

Overview</strong>
    This guide shows how to deploy a pre-built container to fly.io</strong> using Podman</strong>, bypassing Docker. It assumes you already have a container image with digest 7a7bb109</code> and an existing app named buxbunny</code>.</p>

Steps</strong>
    1. Tag Your Local Image</strong>
    Assign the image to the fly.io registry:</p>
podman</span></span> tag 7a7bb109 registry.fly.io/buxbunny:latest  </span>
</span></code></pre>

2. Create a Deploy Token and Log In</strong>
    Generate a deploy token and use it to authenticate with Podman in one step:</p>
flyctl</span></span> tokens create deploy</span> |</span> podman</span></span> login -</span>u</span> x --</span>password-stdin</span> registry.fly.io/buxbunny  </span>
</span></code></pre>

3. Push the Image</strong>
    Upload the tagged image to the fly.io registry:</p>
podman</span></span> push registry.fly.io/buxbunny:latest  </span>
</span></code></pre>

4. Deploy Using fly.toml</code></strong>
    Update fly.toml</code> to use the pre-built image:</p>
#</span>..</span>
</span>
</span>[</span>build</span></span>]</span>  </span>
</span>image</span></span> =</span> "</span>registry.fly.io/buxbunny:latest"</span></span>  </span>
</span>
</span>#</span>..</span>
</span></code></pre>
Then deploy:</p>
flyctl</span></span> deploy --</span>app</span> buxbunny  </span>
</span></code></pre>

Key Notes</strong>
    
Ensure the registry URL and app name in fly.toml</code> match your setup</li>
No Dockerfile</code> or build context is required when using the image</code> field</li>
</ul>

Original source: https://community.fly.io/t/howto-use-podman-instead-of-docker-for-local-builds-and-uploading-container-images/542</a></p>


Stumbling blocks - the Quectel EM05-G LTE Modem under Fedora 39
2024-05-10T00:00:00+00:00
An attempt to collect all scattered information, yielding a successful connection to a LTE network using the Quectel EM05-G</code> as found in the Lenovo T14s Gen 3 AMD</code>.
The below is not a one-size-fits-all solution, but a key-value, problem-solution approach with a defined goal.</p>


Open
2023-11-01T00:00:00+00:00
If you're in need for a rust focused backend, embedded, protocols, applied-cryptography, code generators, GPUs or accelerators, transpilers or compilers, I might be just the right engineer for the job.</p>

konifay - Blog

glibc Symbol Versioning — what it is, how to control it, and how to verify it

Cross-Compiling a rust app for target aarch64 on host x86_64 using Fedora 42

tl;dr </path> </svg> </a> </h2> Proper sysroot setup with --installroot</code></li> </ol> Installing all</strong> native dependencies in the sysroot</li> </ul> Cargo configuration to pass sysroot to compiler and linker invocations</li>

`diesel-rs` ORM - typed SQL `sum(BigInt)` invocations

From `Containerfile` via `podman` to `fly.io`

Key Notes</strong> </path> </svg> </a> </h3> Ensure the registry URL and app name in fly.toml</code> match your setup</li>

Stumbling blocks - the Quectel EM05-G LTE Modem under Fedora 39

Open