# glibc Published articles for glibc. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Java To Native Linux App: One 5MB Binary, x64 And Arm DevFeed: [Java To Native Linux App: One 5MB Binary, x64 And Arm]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-20T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Linux](), [Java](), [App](), [Arm](), [OpenGL]() Tags: [arm](), [glibc](), [java](), [linux](), [native](), [port]() ### AI overview This article explains Codename One's native Linux desktop port. ParparVM translates Java and Kotlin bytecode to C, which is compiled into a self-contained ELF binary without requiring a JVM on the target machine. It describes the GTK-based rendering stack, native integrations, packaging approach, dependencies, and support for x64, arm64, and musl-based Alpine Linux. ### Source excerpt The new native Linux port compiles your Java to a single self-contained ELF through ParparVM and GTK3, with no JVM on the target machine. It runs on an ancient universal glibc, supports musl for Alpine, and ships for both x64 and arm64. ## This Shit is Hard: Hardening glibc DevFeed: [This Shit is Hard: Hardening glibc]() Original publisher: [Read original article]() Published: 2025-08-20T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Security](), [Compiler](), [gcc](), [toolchain](), [chainguard](), [chainguard packages](), [C](), [Linux]() Tags: [c](), [c-c-plus-plus](), [chainguard](), [chainguard-containers](), [chainguard-security](), [compiler](), [compiler-flags](), [gcc](), [glibc](), [hardening](), [openssf](), [security](), [toolchain]() ### AI overview Chainguard describes its effort to build glibc with hardened compiler flags. The work involved collaboration with the upstream GCC and glibc projects to resolve complex issues and ship a hardened version of the library. ### Source excerpt Chainguard uses compiler flags to be proactive in the security of our products. See how our compiler flag usage helped us catch a complex bug in glibc. ## Ekapkgs, a poly-repo fork of Nixpkgs DevFeed: [Ekapkgs, a poly-repo fork of Nixpkgs]() Original publisher: [Read original article]() Author: Jon Ringer Published: 2025-03-31T00:00:00Z Content type: opinion Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [repo](), [Development](), [Maintainability](), [cloud-infrastructure]() Tags: [development](), [fork](), [glibc](), [infrastructure](), [maintainability](), [openssl](), [repo]() ### AI overview The article presents Ekapkgs as a poly-repository fork of Nixpkgs. It argues that Nixpkgs' monolithic scale, lengthy RFC process, and staging workflow make maintenance, convention changes, and package updates difficult, while separate repositories could enable faster iteration and more focused curation. ### Source excerpt Ekapkgs forks Nixpkgs, splitting it into repos for faster updates & easier curation. Ditch monolithic development flows & slow RFCs. Innovate freely! ## C++ exception performance three years later DevFeed: [C++ exception performance three years later]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2024-12-10T14:44:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [C++](), [Exception](), [Scalability](), [gcc](), [JIT](), [LLVM]() Tags: [benchmark](), [c-plus-plus](), [clang](), [exception](), [gcc](), [glibc](), [jit](), [llvm](), [performance](), [series]() ### AI overview The article reviews improvements to C++ exception unwinding performance. Lock-free lookup mechanisms in glibc and libgcc improve scalability for statically generated and JIT-generated code, although clang's implementation may still have scaling limitations. ### Source excerpt About three years ago we noticed serious performance problems in C++ exception unwinding. Due to contention on the unwinding path these became more and more severe the more cores a system had, and unwinding could slow down by orders of magnitude. Due to the constraints of backwards compatibility this contention was not easy to eliminate, and P2544 discussed ways to fix this problem via language changes in C++. But fortunately people found less invasive solutions. First, Florian Weimer changed the glibc to provide a lock-free mechanism to find the (static) unwind tables for a given shared object. Which eliminates the most serious contention for "simple" C++ programs. For example in a micro-benchmark that calls a function with some computations (100 calls to sqrt per function invocation), and which throws with a certain probability, we previously had very poor scalability with increasing core count. With his patch we now see with gcc 14.2 on a dual-socket EPYC 7713 the following performance development (runtime in ms): 1 2 4 8 16 32 64 128 threads 0% failure 29 29 29 29 29 29 29 42 0.1% failure 29 29 29 29 29 29 29 32 1% failure 29 30 30 30 30 30 32 34 10% failure 36 36 37 37 37 37 47 65 Which is more or less perfect. 128 threads are a bit slower, but that is to be expected as one EPYC only has 64 cores. With higher failure rates unwinding itself becomes slower but that is still acceptable here. Thus most C++ programs are just fine. For our use case that is not enough, though. We dynamically generate machine code at runtime, and we want to be able to pass exceptions through generated code. The _dl_find_object mechanism of glibc is not used for JITed code, instead libgcc maintains its own lookup structure. Historically this was a simple list with a global lock, which of course had terrible performance. But through a series of patches we managed to change libgcc into using a lock-free b-tree for maintaining the dynamic unwinding frames. Using a similar experiment to the ## Why pipes sometimes get "stuck": buffering DevFeed: [Why pipes sometimes get "stuck": buffering]() Original publisher: [Read original article]() Author: Julia Evans Published: 2024-11-29T08:23:31Z Content type: article Language: en Sources: [Julia Evans]() Topics: [Terminal](), [Command-line interface](), [Streams]() Tags: [deep-dive](), [glibc](), [implementation](), [libc](), [performance](), [terminal]() ### AI overview This article explains why output from commands in Unix pipelines can appear to get stuck. Programs such as grep often use block buffering when writing to a pipe, so matches may remain in memory until the buffer fills or the program exits. When output goes directly to a terminal, line buffering usually makes each line appear immediately. The behavior depends on the program's implementation and, in the case discussed, libc and glibc. ### Source excerpt Here's a niche terminal problem that has bothered me for years but that I never really understood until a few weeks ago. Let's say you're running this command to watch for some specific output in a log file: tail -f /some/log/file | grep thing1 | grep thing2 If log lines are being added to the file relatively slowly, the result I'd see is... nothing! It doesn't matter if there were matches in the log file or not, there just wouldn't be any output. I internalized this as "uh, I guess pipes just get stuck sometimes and don't show me the output, that's weird", and I'd handle it by just running grep thing1 /some/log/file | grep thing2 instead, which would work. So as I've been doing a terminal deep dive over the last few months I was really excited to finally learn exactly why this happens. why this happens: buffering The reason why "pipes get stuck" sometimes is that it's VERY common for programs to buffer their output before writing it to a pipe or file. So the pipe is working fine, the problem is that the program never even wrote the data to the pipe! This is for performance reasons: writing all output immediately as soon as you can uses more system calls, so it's more efficient to save up data until you have 8KB or so of data to write (or until the program exits) and THEN write it to the pipe. In this example: tail -f /some/log/file | grep thing1 | grep thing2 the problem is that grep thing1 is saving up all of its matches until it has 8KB of data to write, which might literally never happen. programs don't buffer when writing to a terminal Part of why I found this so disorienting is that tail -f file | grep thing will work totally fine, but then when you add the second grep, it stops working!! The reason for this is that the way grep handles buffering depends on whether it's writing to a terminal or not. Here's how grep (and many other programs) decides to buffer its output: Check if stdout is a terminal or not using the isatty function If it's a terminal, use line b ## Chainguard Images CVE patch report: Securing software supply chains DevFeed: [Chainguard Images CVE patch report: Securing software supply chains]() Original publisher: [Read original article]() Published: 2024-05-01T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [supply-chain-security](), [container images](), [Vulnerabilities]() Tags: [chainguard-images](), [cve](), [glibc](), [php](), [security](), [software-supply-chain](), [software-supply-chain-security]() ### AI overview Chainguard reports that Chainguard Images removed 150 CVEs from customer and user environments in March and April 2024, including high- and critical-severity vulnerabilities affecting Kubernetes, Apache HTTP server, glibc, and PHP. The article explains how Wolfi rapidly replaces affected packages and propagates fixes to dependent container images, with an average process time of 26 hours. ### Source excerpt Discover how Chainguard Images helped remove 150+ CVEs in March and April 2024. Learn more about our commitment to securing your software supply chain. ## Installing Oracle Instant Client on Ubuntu 24.04 DevFeed: [Installing Oracle Instant Client on Ubuntu 24.04]() Original publisher: [Read original article]() Author: Tom Published: 2024-04-17T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Ubuntu](), [docker images](), [Docker](), [Containers]() Tags: [debian](), [debian-oracle-client](), [docker](), [docker-images](), [glibc](), [how-to](), [install](), [install-oracle-client](), [linux](), [linux-database-tools](), [oracle-client-docker](), [oracle-instant-client](), [ubuntu](), [ubuntu-24-04]() ### AI overview A tutorial on installing Oracle Instant Client on Ubuntu and Debian, presenting the recommended ZIP-package approach and an alternative RPM-based approach. It focuses on Docker image workflows and discusses library paths, linker cache configuration, package compatibility, and central package repositories. ### Source excerpt Learn how to install Oracle Instant Client on Ubuntu 24.04 using both recommended and alternative methods, with a focus on Docker images. ## Underrust: What does vec!\[0u8; 1024\] really do? DevFeed: [Underrust: What does vec!\[0u8; 1024\] really do?]() Original publisher: [Read original article]() Author: Graham King Published: 2024-03-29T15:00:00Z Content type: article Language: en Sources: [Graham King]() Topics: [Rust](), [Linux](), [cpu]() Tags: [code](), [cpu](), [glibc](), [linux](), [memory](), [rust](), [software](), [underrust](), [x86]() ### AI overview This article traces how Rust creates a zero-initialized vector, following the allocation path through Rust's allocator, the platform abstraction layer, libc's calloc, and the Linux kernel. It examines allocation behavior and cost, with examples focused on 64-bit Linux, glibc, and an Intel Tiger Lake CPU. ### Source excerpt How does Rust allocate a zeroed Vec and what does it cost? ## Chainguard's response to CVE-2023-6246 in glibc DevFeed: [Chainguard's response to CVE-2023-6246 in glibc]() Original publisher: [Read original article]() Published: 2024-02-01T00:00:00Z Content type: news Language: en Sources: [Chainguard: Unchained]() Topics: [Security](), [container-security](), [chainguard images](), [Vulnerabilities](), [chainguard]() Tags: [chainguard](), [chainguard-images](), [container-image](), [container-image-security](), [cve](), [cve-2023-6246](), [deployment](), [glibc](), [security](), [wolfi]() ### AI overview Chainguard describes its response to CVE-2023-6246, a glibc heap-based buffer overflow that can enable local privilege escalation. The team patched the glibc Wolfi package and rebuilt affected Chainguard Images after coordinated disclosure. ### Source excerpt Chainguard swiftly addresses CVE-2023-6246 in glibc, reinforcing container image security with rapid patch deployment and updated advisories. ## The memory remains: Permanent memory with systemd and a Rust allocator DevFeed: [The memory remains: Permanent memory with systemd and a Rust allocator]() Original publisher: [Read original article]() Author: Graham King Published: 2024-01-10T01:54:00Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Rust](), [systemd](), [file](), [Linux]() Tags: [assembly](), [file](), [function](), [glibc](), [layout](), [memory](), [mmap](), [pointers](), [rust](), [software](), [systemd]() ### AI overview This tutorial explains how to make Rust objects survive program restarts by combining Rust's Allocator trait with systemd's File Descriptor Store and Linux's memfd_create syscall. The approach stores allocator-backed memory in an in-memory file, maps it with mmap, and restores it after restart. ### Source excerpt A Rust object that survives program restart thanks to Rust allocators, systemd's file descriptor store, and syscall memfd_create. ## Chainguard's response to CVE-2023-4527 in glibc DevFeed: [Chainguard's response to CVE-2023-4527 in glibc]() Original publisher: [Read original article]() Published: 2023-09-25T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Security](), [vulnerability](), [chainguard](), [chainguard images]() Tags: [chainguard-images](), [cve](), [cve-2023-4527](), [glibc](), [network](), [nvd](), [pull-request](), [security](), [vulnerability](), [wolfi]() ### AI overview Chainguard describes its response to CVE-2023-4527 in glibc, a network-exploitable vulnerability involving getaddrinfo, AF_UNSPEC, no-aaaa mode, and oversized DNS-over-TCP responses. The team detected the CVE, prepared and merged a Wolfi patch, built a fixed glibc APK, published it, and updated advisory data. ### Source excerpt Swift action on CVE-2023-4527 in glibc: Discover how Chainguard ensured user security promptly. ## Chainguard Images now available to government agencies on U.S. Air Force Platform One DevFeed: [Chainguard Images now available to government agencies on U.S. Air Force Platform One]() Original publisher: [Read original article]() Published: 2023-04-18T00:00:00Z Content type: news Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [chainguard images](), [supply-chain-security](), [container images](), [DevSecOps](), [Containers](), [Kubernetes](), [Infrastructure as code]() Tags: [arm](), [chainguard](), [chainguard-images](), [container](), [container-images](), [devsecops](), [glibc](), [government](), [iron-bank](), [node](), [platform-one](), [python](), [sbom](), [software-supply-chain](), [software-supply-chain-security](), [vulnerabilities](), [wolfi](), [x86-64]() ### AI overview Chainguard Images, including Python and Node images, are now available to U.S. government agencies through the U.S. Air Force's Platform One and its authorized Iron Bank container repository. The article explains how Wolfi and Chainguard Images support hardened, lightweight containers with build-time SBOMs, reproducible builds, reduced vulnerabilities, and faster deployments. ### Source excerpt Wolfi has been accepted into Platform One, U.S. Air Force's DevSecOps platform. Chainguard Images are now available on Platform One via container repo Iron Bank ## Quest for the Lost Home Server DevFeed: [Quest for the Lost Home Server]() Original publisher: [Read original article]() Published: 2019-10-14T22:00:00Z Content type: article Language: en Sources: [Dennis Felsing]() Topics: [Homelab](), [OpenSSH](), [Hardware](), [systems](), [backups]() Tags: [backups](), [cpu](), [glibc](), [hardware](), [home-server](), [intel](), [ssh]() ### AI overview A remote troubleshooting account of recovering access to a home server after SSH connections and pings failed. The author traced the problem to a changed dynamic IP address, found the server by scanning the likely ISP subnet on a custom SSH port, and identified cronie's inability to spawn processes after a glibc update. ### Source excerpt Today I lost access to my home server. As I described in a previous post I depend heavily on the server to fetch my emails, as a file server, to synchronize files, for newsbeuter and irssi sessions and many other things. As no one was going to be in proximity of the server for the next few hours, my goal for today was to solve the problem remotely. The symptom was that my SSH connection attempts failed. The server also didn't respond to pings. As the server is sitting at home behind a regular DSL connection it uses a dynamic IP address that is shuffled every 24 hours. So my first hunch was that the daily reconnect might just have happened at a different time today and I gave the server some time to broadcast its new IP address to my domain registrar. After about an hour I still couldn't connect, so I started investigating. Maybe the API of the domain registrar changed (as happened before) or my script failed for another reason? I know that my home server does nightly backups of the other servers I run. So I connected to one of them and checked the journalctl log. To my surprise no connection from the server happened last night. My worst fear was that the server was hanging due to a hardware problem, as I ran into similar problems with this Intel Bay Trail CPU before. (The issue seems to be that Intel underdesigned the power delivery on those systems, which the graphics driver is trying to work around.) But I wasn't ready to give up yet, so I tried to think of any other activities the server would do that might leave a trace. I found out that my email hoster doesn't provide easy access to the IP addresses that access the mailbox. I couldn't think of any other traces at the time, but next time I might check if my IP address is visible on some IRC server. As a last resort I remembered that my ISP usually gives me quite similar IP addresses, so I used whois on yesterday's IP address to see how large the subnet is. I got back a subnet of only 2¹⁴ addresses, which seemed ## Nim binary size from 160 KB to 150 Bytes DevFeed: [Nim binary size from 160 KB to 150 Bytes]() Original publisher: [Read original article]() Published: 2015-05-03T22:00:00Z Content type: tutorial Language: en Sources: [Dennis Felsing]() Topics: [Nim](), [Programming](), [Compiler](), [Linux]() Tags: [c](), [clang](), [compilation](), [compiler](), [gcc](), [glibc](), [linux](), [measurements](), [nim](), [x86]() ### AI overview This tutorial explores how to reduce the size of a simple Nim binary on Linux. It demonstrates builds using GCC and Clang, including a 6 KB binary, a 952-byte binary without the C standard library, and a 150-byte binary using a custom linker script and ELF header. ### Source excerpt The size of binaries in the Nim programming language seems to be a popular topic recently. Nim's slogan is expressive, efficient, elegant, so let's examine the efficient part in this post by exploring a few ways to reduce the size of a simple Nim Hello World binary on Linux. Along the way we will: Build a regular program into a 6 KB binary Disregard the C standard library and build a 952 byte binary Use a custom linker script and ELF header to build a 150 byte binary (1 byte smaller than in Rust) The full source code of this post can be found in its repository. All measurements are done on Linux x86-64 with GCC 5.1 and Clang 3.6.0. Using the C Standard Library echo "Hello!" By default Nim uses GCC as the backend C compiler on most platforms, and we dynamically link against glibc. We can try optimizing for speed and size, as well as strip unnecessary symbols after the compilation: Command (GCC backend) Binary Size nim c hello 160 KB nim -d:release c hello 61 KB nim -d:release --opt:size c hello 25 KB nim -d:release --opt:size c hello && strip -s hello 19 KB That's pretty nice and can be done with any Nim program to reduce binary size. Now let's try to get rid of glibc, at least temporarily (we will come back to a more permanent solution later). Instead of glibc we're now statically linking against musl libc: $ nim --gcc.exe:/usr/local/musl/bin/musl-gcc \ --gcc.linkerexe:/usr/local/musl/bin/musl-gcc \ -d:release --opt:size --passL:-static c hello $ strip -s hello 30 KB Update: The order of arguments to nim matters, --passL:-static has to be passed after setting the gcc exe so that it isn't overwritten. So that's a statically linked binary in 30 KB, which can be deployed without depending on any glibc version (or any other libraries)! What about using Clang instead of GCC by setting --cc:clang: Command (Clang backend) Binary Size nim --cc:clang c hello 168 KB nim --cc:clang -d:release c hello 33 KB nim --cc:clang -d:release --opt:size c hello 29 KB nim --cc:clang -d:re ## When printf debugging is a luxury DevFeed: [When printf debugging is a luxury]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2010-12-18T19:06:00Z Content type: tutorial Language: en Sources: [Mark Seaborn]() Topics: [debugging](), [Code](), [Linux](), [Chromium]() Tags: [chromium](), [code](), [debugging](), [glibc](), [libc](), [linux](), [native-client](), [sandbox]() ### AI overview This article explains why printf() and assert() may be unavailable in certain low-level programming contexts, including signal handlers, limited-stack environments, and code that cannot use libc. It presents a simple assertion implementation that constructs failure messages at compile time and discusses bypassing libc to invoke Linux system calls when TLS register state makes libc wrappers unusable. ### Source excerpt Inserting printf() calls is often considered to be a primitive fallback when other debugging tools are not available, such as stack backtraces with source line numbers. But there are some situations in low-level programming where most libc calls don't work and so even printf() and assert() are unavailable luxuries. This can happen: when libc is not properly initialised yet; when we writing code that is called by libc and cannot re-enter libc code; when we are in a signal handler; when only limited stack space is available; when we cannot allocate memory for some reason; or when we are not even linked to libc. Here's a fragment of code that has come in handy in these situations. It provides a simple assert() implementation: #include #include static void debug(const char *msg) { write(2, msg, strlen(msg)); } static void die(const char *msg) { debug(msg); _exit(1); } #define TO_STRING_1(x) #x #define TO_STRING(x) TO_STRING_1(x) #define assert(expr) { \ if (!(expr)) die("assertion failed at " __FILE__ ":" TO_STRING(__LINE__) \ ": " #expr "\n"); } By using preprocessor trickery to construct the assertion failure string at compile time, it avoids having to format the string at runtime. So it does not need to allocate memory, and it doesn't need to do multiple write() calls (which can become interleaved with other output in the multi-threaded case). Sometimes even libc's write() is a luxury. In some builds of GNU libc on Linux, glibc's syscall wrappers use the TLS register (%gs on i386) to fetch the address of a routine for making syscalls. However, if %gs is not set up properly for some reason, this will fail. For example, for Native Client's i386 sandbox, %gs is set to a different value whenever sandboxed code is running, and %gs stays in this state if sandboxed code faults and triggers a signal handler. In Chromium's seccomp-sandbox, %gs is set to zero in the trusted thread. In those situations we have to bypass libc and do the system calls ourselv ## Building a deterministic profiler for mixed C and Perl code DevFeed: [Building a deterministic profiler for mixed C and Perl code]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2010-05-23T19:53:30Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Perl](), [C](), [debug]() Tags: [c](), [debug](), [function](), [gcc](), [glibc](), [memory](), [perl](), [profiling](), [tools]() ### AI overview The author describes trying to improve profiling visibility in BarnOwl, a program that mixes C and Perl. Statistical profilers could show time spent in Perl but not which C functions led to those calls, so the author explores a deterministic profiler that tracks function entries and returns. ### Source excerpt Recently, I've been working on some BarnOwl branches that move more of the core functionality of BarnOwl into perl code, instead of C (BarnOwl is written in an unholy mix of C and perl code that call each other back and forth obsessively). Moving code into perl has many advantages, but one problem is speed - perl code is obvious a lot slower than C, and BarnOwl has a lot of hot spots related to its tendency to keep tens or hundreds of thousands of messages in memory and loop over all of them in response to various commands. ## Breakpoints in gdb using int3 DevFeed: [Breakpoints in gdb using int3]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2010-05-01T11:59:00Z Content type: tutorial Language: en Sources: [Mark Seaborn]() Topics: [debugging](), [Assembly](), [x86](), [Linux](), [Ubuntu]() Tags: [assembly](), [breakpoint](), [debugging](), [debugging-tools](), [gdb](), [glibc](), [linux](), [memory](), [signal](), [x86](), [x86-64]() ### AI overview This article explains how inserting the x86 int3 instruction, for example through __asm__("int3"), can trigger a breakpoint while debugging with gdb. It notes that int3 raises SIGTRAP, allowing inspection of registers, memory, and the call stack under gdb, and can be useful when setting a source-line breakpoint is impractical, such as within inline assembly. ### Source excerpt Here is a useful trick I discovered recently while debugging some changes to the seccomp sandbox. To trigger a breakpoint on x86, just do: __asm__("int3"); Then it is possible to inspect registers, memory, the call stack, etc. in gdb, without having to get gdb to set a breakpoint. The instruction triggers a SIGTRAP, so if the process is not running under gdb and has no signal handler for SIGTRAP, the process will die. This technique seems to be fairly well known, although it's not mentioned in the gdb documentation. int3 is the instruction that gdb uses internally for setting breakpoints. Sometimes it's easier to insert an int3 and rebuild than get gdb to set a breakpoint. For example, setting a gdb breakpoint on a line won't work in the middle of a chunk of inline assembly. My expectations of gdb are pretty low these days. When I try to use it to debug something low level, it often doesn't work, which is why I have been motivated to hack together my own debugging tools in the past. For example, if I run gdb on the glibc dynamic linker (ld.so) on Ubuntu Hardy or Karmic, it gives: $ gdb /lib/ld-linux-x86-64.so.2 ... (gdb) run Starting program: /lib/ld-linux-x86-64.so.2 Cannot access memory at address 0x21ec88 (gdb) So it's nice to find a case where I can get some useful information out of gdb.