{"slug": "glibc", "name": "glibc", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 3, "commenters": 19, "warners": 14, "score": -9.077, "rising": -0.98, "first": "2025-11-02", "latest": "2026-10-16", "why": "The glibc people are so serious about backward and forward compatibility", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 2, "compare": 0, "warn": 14}, "spark": [0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "The glibc people are so serious about backward and forward compatibility", "kind": "", "icon": true, "domain": null, "github_repo": "github.com/lattera/glibc", "official_url": "https://www.gnu.org/software/libc/", "pricing": "", "aliases": ["glibc"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 757725760, "item_id": 47357860, "url": "https://news.ycombinator.com/item?id=47357860", "by": "kazinator", "date": "2026-03-12", "stance": "recommend", "quote": "they are doing a more assiduous job", "excerpt": "The glibc implementation already has tests for several ranges and hacks for them including Taylor series: https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_asin.c The smallest range is |x| < 1.49011611938477e-8. In this case the routine just returns x, after calling some underflow-checking routine. So right there, if we neglect this detail in our own wrapper, we may be able to get a speedup, at th", "context": "", "use_case": "C math library", "switched_from": "", "story": "Faster Asin() Was Hiding in Plain Sight"}, {"id": 752491232, "item_id": 47030702, "url": "https://news.ycombinator.com/item?id=47030702", "by": "eqvinox", "date": "2026-02-15", "stance": "recommend", "quote": "how many other things do you know where you need to go back 12 years to find an ABI break?", "excerpt": "> https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a \"change in glibc that makes things not work anymore\". You also can't execute a.out binaries anymore, eh. And I don't think I wo", "context": "", "use_case": "C standard library", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 752445904, "item_id": 47027869, "url": "https://news.ycombinator.com/item?id=47027869", "by": "eqvinox", "date": "2026-02-15", "stance": "recommend", "quote": "The glibc people are so serious about backward and forward compatibility", "excerpt": "> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.n", "context": "", "use_case": "", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 747381328, "item_id": 46711333, "url": "https://news.ycombinator.com/item?id=46711333", "by": "yread", "date": "2026-01-21", "stance": "recommend", "quote": "if glibc can do it, why not!", "excerpt": "https://www.linuxfromscratch.org/lfs/view/stable/chapter08/glibc.html > the test suite for Glibc is considered critical. Do not skip it under any circumstance. > Generally a few tests do not pass. The test failures listed below are usually safe to ignore. I felt a bit uneasy writing something similar into my software e2e test suite, but hey if glibc can do it, why not! > It's imperative to strictly follow these steps", "context": "", "use_case": "", "switched_from": "", "story": "Linux from Scratch"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 801852149, "item_id": 50115759, "url": "https://news.ycombinator.com/item?id=50115759", "by": "delta_p_delta_x", "date": "2026-10-16", "stance": "warn", "quote": "glibc has an unstable ABI", "excerpt": "There is not some arbitrary notion of wheel reinvention just for browsers. Calling browsers 'just browsers' is doing their feature set a huge disservice: they are bona fide operating systems or virtual machines, which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more), and do a ", "context": "", "use_case": "", "switched_from": "", "story": "Last rites for Gentoo's Chromium package"}, {"id": 789894289, "item_id": 49368393, "url": "https://news.ycombinator.com/item?id=49368393", "by": "okanat", "date": "2026-08-19", "stance": "warn", "quote": "A breakage hasn't been observed doesn't mean that there is no tight-coupling between ld-linux.so and glibc", "excerpt": "Here read it from the lion's mouth: https://wiki.musl-libc.org/design-concepts > Then, what is the exact reason a library compiled against glibc must be loaded by a specific ld-linux? I could see that this is true for C++ perhaps, or when you use very special features, but I do not see this for C. You still have functionality like `dlopen` with C or `pthreads` with C. ld-linux.so is the thing that prepares the stack ", "context": "", "use_case": "", "switched_from": "", "story": "Solo \u2013 a .so loader for static Linux binaries"}, {"id": 789686048, "item_id": 49355378, "url": "https://news.ycombinator.com/item?id=49355378", "by": "pg83", "date": "2026-08-18", "stance": "warn", "quote": "https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most \"famous\" example.", "excerpt": "https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most \"famous\" example. There are also much less well-known \"little things\" that regularly pop up here and there. > If your CI uses an older glibc you should be fine AFAIK. In any case, my binaries work not only under glibc, but also under Alpine, and (work in progress) under android/bionic.", "context": "", "use_case": "C standard library", "switched_from": "", "story": "Solo \u2013 a .so loader for static Linux binaries"}, {"id": 769166608, "item_id": 48072913, "url": "https://news.ycombinator.com/item?id=48072913", "by": "andriamanitra", "date": "2026-05-09", "stance": "warn", "quote": "The dependency on glibc is an unfortunate limitation", "excerpt": "The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems. [1] https://mojolang.org/releases/v1.0.0b1/", "context": "", "use_case": "C standard library", "switched_from": "", "story": "Mojo 1.0 Beta"}]}], "who": [], "tags": [], "use_cases": ["c standard library", "c math library", "dynamic library loading", "libc"], "compared": [{"slug": "musl", "name": "musl", "co": 13, "switched_from": 0, "switched_to": 2}, {"slug": "alpine-linux", "name": "Alpine Linux", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "busybox", "name": "BusyBox", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "gcc", "name": "GCC", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 790128934, "item_id": 49383058, "url": "https://news.ycombinator.com/item?id=49383058", "by": "collinfunk", "date": "2026-08-20", "stance": "neutral", "quote": "I am a committer to glibc", "excerpt": "> Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales? Most GNU projects don't have a large overlap, if any overlap at all, between their active contributors. I suspect they behave far more independently than you expect. Also, GNU didn't invent locales, if that is what you are getting at. > As it stands I am generally averse to using GNU tools because my feeling", "context": "", "use_case": "", "switched_from": "", "story": "Rewriting in Rust"}], "threads": [{"url": "https://news.ycombinator.com/item?id=47022891", "title": "I Fixed Windows Native Development", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=49354613", "title": "Solo \u2013 a .so loader for static Linux binaries", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50114359", "title": "Last rites for Gentoo's Chromium package", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49419252", "title": "What's new in Emacs 31.1", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49315372", "title": "Rewriting in Rust", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49192556", "title": "Python string literals are kinda funny", "mentions": 1}], "sentiment_by_month": {"2025-11": {"warn": 2}, "2025-12": {"warn": 1}, "2026-01": {"warn": 3, "recommend": 1}, "2026-02": {"recommend": 1, "warn": 1}, "2026-03": {"warn": 2, "recommend": 1}, "2026-04": {}, "2026-05": {"warn": 2}, "2026-06": {}, "2026-07": {}, "2026-08": {"neutral": 2, "warn": 2}, "2026-09": {}, "2026-10": {"warn": 1}}, "quotes": [{"id": 801852149, "item_id": 50115759, "url": "https://news.ycombinator.com/item?id=50115759", "by": "delta_p_delta_x", "date": "2026-10-16", "stance": "warn", "quote": "glibc has an unstable ABI", "excerpt": "There is not some arbitrary notion of wheel reinvention just for browsers. Calling browsers 'just browsers' is doing their feature set a huge disservice: they are bona fide operating systems or virtual machines, which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more), and do a ", "context": "", "use_case": "", "switched_from": "", "story": "Last rites for Gentoo's Chromium package"}, {"id": 790999600, "item_id": 49437475, "url": "https://news.ycombinator.com/item?id=49437475", "by": "Asooka", "date": "2026-08-25", "stance": "neutral", "quote": "the glibc people simply didn't want the support burden", "excerpt": "There was a lot of discussion around the time it was being removed[0], but it seems the glibc people simply didn't want the support burden and Emacs was the single user of that interface. I think the issues could have been resolved by checking if all shared libraries are exactly the same as when unexec was called, that the kernel is the same and that the CPU is the same, and failing if anything doesn't match, thus fa", "context": "", "use_case": "", "switched_from": "", "story": "What's new in Emacs 31.1"}, {"id": 789894289, "item_id": 49368393, "url": "https://news.ycombinator.com/item?id=49368393", "by": "okanat", "date": "2026-08-19", "stance": "warn", "quote": "A breakage hasn't been observed doesn't mean that there is no tight-coupling between ld-linux.so and glibc", "excerpt": "Here read it from the lion's mouth: https://wiki.musl-libc.org/design-concepts > Then, what is the exact reason a library compiled against glibc must be loaded by a specific ld-linux? I could see that this is true for C++ perhaps, or when you use very special features, but I do not see this for C. You still have functionality like `dlopen` with C or `pthreads` with C. ld-linux.so is the thing that prepares the stack ", "context": "", "use_case": "", "switched_from": "", "story": "Solo \u2013 a .so loader for static Linux binaries"}, {"id": 789686048, "item_id": 49355378, "url": "https://news.ycombinator.com/item?id=49355378", "by": "pg83", "date": "2026-08-18", "stance": "warn", "quote": "https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most \"famous\" example.", "excerpt": "https://bugzilla.redhat.com/show_bug.cgi?id=638477 is the most \"famous\" example. There are also much less well-known \"little things\" that regularly pop up here and there. > If your CI uses an older glibc you should be fine AFAIK. In any case, my binaries work not only under glibc, but also under Alpine, and (work in progress) under android/bionic.", "context": "", "use_case": "C standard library", "switched_from": "", "story": "Solo \u2013 a .so loader for static Linux binaries"}, {"id": 787621312, "item_id": 49226332, "url": "https://news.ycombinator.com/item?id=49226332", "by": "layer8", "date": "2026-08-08", "stance": "neutral", "quote": "GNU libc does let you extend it", "excerpt": "I\u2019m not sure what you mean by manual formatting. You do need a place in your program where you fill in the parameters into the respective localized string template. I agree that the printf format syntax is somewhat limited for localization [0]. But whatever localization string format you use, you don\u2019t want arbitrary expressions embeddable within it. [0] though GNU libc does let you extend it: https://sourceware.org/", "context": "", "use_case": "", "switched_from": "", "story": "Python string literals are kinda funny"}, {"id": 769166608, "item_id": 48072913, "url": "https://news.ycombinator.com/item?id=48072913", "by": "andriamanitra", "date": "2026-05-09", "stance": "warn", "quote": "The dependency on glibc is an unfortunate limitation", "excerpt": "The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems. [1] https://mojolang.org/releases/v1.0.0b1/", "context": "", "use_case": "C standard library", "switched_from": "", "story": "Mojo 1.0 Beta"}, {"id": 768891024, "item_id": 48055689, "url": "https://news.ycombinator.com/item?id=48055689", "by": "chuckadams", "date": "2026-05-07", "stance": "warn", "quote": "The weakness is embedded into the architecture of glibc", "excerpt": "xz was not directly linked to ssh, and systemd itself was not providing the backdoor. The weakness is embedded into the architecture of glibc (which has spread to other systems like FreeBSD as well): https://github.com/robertdfrench/ifuncd-up", "context": "", "use_case": "", "switched_from": "", "story": "Dirtyfrag: Universal Linux LPE"}, {"id": 760170720, "item_id": 47510670, "url": "https://news.ycombinator.com/item?id=47510670", "by": "em-bee", "date": "2026-03-24", "stance": "warn", "quote": "The only problem with this approach is that glibc cannot have multiple versions running at once", "excerpt": "The only problem with this approach is that glibc cannot have multiple versions running at once that's not correct. libraries have versions for a reason. the only thing preventing the installation of multiple glibc versions is the package manager or the package versioning. this makes building against an older version of glibc non-trivial, because there isn't a ready made package that you can just install. the workaro", "context": "", "use_case": "", "switched_from": "", "story": "Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains"}, {"id": 757725760, "item_id": 47357860, "url": "https://news.ycombinator.com/item?id=47357860", "by": "kazinator", "date": "2026-03-12", "stance": "recommend", "quote": "they are doing a more assiduous job", "excerpt": "The glibc implementation already has tests for several ranges and hacks for them including Taylor series: https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_asin.c The smallest range is |x| < 1.49011611938477e-8. In this case the routine just returns x, after calling some underflow-checking routine. So right there, if we neglect this detail in our own wrapper, we may be able to get a speedup, at th", "context": "", "use_case": "C math library", "switched_from": "", "story": "Faster Asin() Was Hiding in Plain Sight"}, {"id": 755300512, "item_id": 47206282, "url": "https://news.ycombinator.com/item?id=47206282", "by": "Joker_vD", "date": "2026-03-01", "stance": "warn", "quote": "The use of these hook functions is not safe in multithreaded", "excerpt": "The use of these hook functions is not safe in multithreaded programs, and they are now deprecated. From glibc 2.24 onwards, the __malloc_initialize_hook variable has been removed from the API, and from glibc 2.34 onwards, all the hook variables have been removed from the API. Programmers should instead preempt calls to the relevant functions by defining and exporting malloc(), free(), realloc(), and calloc().", "context": "", "use_case": "", "switched_from": "", "story": "Why is the first C++ (m)allocation always 72 KB?"}, {"id": 752886064, "item_id": 47055379, "url": "https://news.ycombinator.com/item?id=47055379", "by": "HexDecOctBin", "date": "2026-02-17", "stance": "warn", "quote": "Some of the most popular games and software broke", "excerpt": "> Because what's at question in this case is the actual impact size, which to me seems quite limited. It was widely covered in media. Some of the most popular games and software broke: 1. https://www.gamingonlinux.com/2025/02/the-glibc-2-41-update-has-been-causing-problems-for-linux-gaming/ 2. https://www.phoronix.com/news/Glibc-WA-Steam-Exec-Stack This is the attitude that will always prevent GNU/Linux from becoming", "context": "", "use_case": "", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 752491232, "item_id": 47030702, "url": "https://news.ycombinator.com/item?id=47030702", "by": "eqvinox", "date": "2026-02-15", "stance": "recommend", "quote": "how many other things do you know where you need to go back 12 years to find an ABI break?", "excerpt": "> https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a \"change in glibc that makes things not work anymore\". You also can't execute a.out binaries anymore, eh. And I don't think I wo", "context": "", "use_case": "C standard library", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 752476624, "item_id": 47029789, "url": "https://news.ycombinator.com/item?id=47029789", "by": "HexDecOctBin", "date": "2026-02-15", "stance": "warn", "quote": "Glibc has been a source of breakage for proprietary software", "excerpt": "> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653 Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first la", "context": "", "use_case": "", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 752445904, "item_id": 47027869, "url": "https://news.ycombinator.com/item?id=47027869", "by": "eqvinox", "date": "2026-02-15", "stance": "recommend", "quote": "The glibc people are so serious about backward and forward compatibility", "excerpt": "> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.n", "context": "", "use_case": "", "switched_from": "", "story": "I Fixed Windows Native Development"}, {"id": 748501552, "item_id": 46781347, "url": "https://news.ycombinator.com/item?id=46781347", "by": "duped", "date": "2026-01-27", "stance": "warn", "quote": "if you've ever dug into the guts of glibc's loader it's 40 years of unreadable cruft", "excerpt": "Missing in this discussion is that package management is tightly coupled to module resolution in nearly every language. It is not enough to merely install dependencies of given versions but to do so in a way that the language toolchain and/or runtime can find and resolve them. And so when it comes to dynamic dependencies (including shared libraries) that are not resolved until runtime you hit language-level constrain", "context": "", "use_case": "dynamic library loading", "switched_from": "", "story": "The C-Shaped Hole in Package Management"}, {"id": 748257777, "item_id": 46766111, "url": "https://news.ycombinator.com/item?id=46766111", "by": "zoobab", "date": "2026-01-26", "stance": "warn", "quote": "The documentation to make static binary with GLibc is sparce for a reason", "excerpt": "I have an idea for a static linux distribution based on musl, with either an Alpine rebuild or Gentoo-musl: http://stalinux.wikidot.com The documentation to make static binary with GLibc is sparce for a reason, they don't like static binaries.", "context": "", "use_case": "", "switched_from": "", "story": "The Holy Grail of Linux Binary Compatibility: Musl and Dlopen"}, {"id": 747381328, "item_id": 46711333, "url": "https://news.ycombinator.com/item?id=46711333", "by": "yread", "date": "2026-01-21", "stance": "recommend", "quote": "if glibc can do it, why not!", "excerpt": "https://www.linuxfromscratch.org/lfs/view/stable/chapter08/glibc.html > the test suite for Glibc is considered critical. Do not skip it under any circumstance. > Generally a few tests do not pass. The test failures listed below are usually safe to ignore. I felt a bit uneasy writing something similar into my software e2e test suite, but hey if glibc can do it, why not! > It's imperative to strictly follow these steps", "context": "", "use_case": "", "switched_from": "", "story": "Linux from Scratch"}, {"id": 746952753, "item_id": 46684547, "url": "https://news.ycombinator.com/item?id=46684547", "by": "1vuio0pswjnm7", "date": "2026-01-19", "stance": "warn", "quote": "Wherever possible I compile with gethostbyname instead of getaddrinfo.  I use musl instead of glibc", "excerpt": "\"One such implementation that broke is the getaddrinfo function in glibc, which is commonly used on Linux for DNS resolution. When looking at its getanswer_r implementation, we can indeed see it expects to find the CNAME records before any answers:\" Wherever possible I compile with gethostbyname instead of getaddrinfo. I use musl instead of glibc Nothing against IPv6 but I do not use it on the computers and networks ", "context": "", "use_case": "C standard library", "switched_from": "", "story": "What came first: the CNAME or the A record?"}, {"id": 740028385, "item_id": 46251774, "url": "https://news.ycombinator.com/item?id=46251774", "by": "jchw", "date": "2025-12-12", "stance": "warn", "quote": "statically linking glibc is not supported and basically does not work", "excerpt": "IMO this is the best approach, but it is worth noting that musl libc is not without its caveats. I'd say for most people it is best to tread carefully and make sure that differences between musl libc and glibc don't cause additional problems for the libraries you are linking to. There is a decent list of known functional differences on the musl libc wiki: https://wiki.musl-libc.org/functional-differences-from-glibc.h", "context": "", "use_case": "", "switched_from": "", "story": "Go is portable, until it isn't"}, {"id": 737449666, "item_id": 46090604, "url": "https://news.ycombinator.com/item?id=46090604", "by": "IshKebab", "date": "2025-11-29", "stance": "warn", "quote": "glibc is a curse", "excerpt": "> Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Have you considered making... Fil-Zig? Would it be easier to do because Zig is already fairly far ahead of C in terms of safety? > Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on ", "context": "", "use_case": "", "switched_from": "", "story": "Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C"}, {"id": 732727110, "item_id": 45795444, "url": "https://news.ycombinator.com/item?id=45795444", "by": "Imustaskforhelp", "date": "2025-11-02", "stance": "warn", "quote": "Glibc has some of the weirdest complexities I have ever seen", "excerpt": "My thoughts on systemd are complicated but I wasn't around at the time of systemd Personally it is my opinion that Linux really split in two due to systemd partially because of the idea of the sheer size of systemd code There are things like https://github.com/Sweets/hummingbird which, I, not even a C person can understand and appreciate its simplicity. I am not saying that we always need such simplicity, but that I ", "context": "", "use_case": "libc", "switched_from": "", "story": null}]}