Debian is switching to EGLIBC

I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is currently waiting in the NEW queue), which will soon replace the GNU C Library (GLIBC).

The EGLIBC is a variant of the GLIBC which stays source and binary compatible with the original GLIBC. While primarily targeted for embedded architectures, it has some really nice points:

We do not use some of these features yet, but this upload is a first step. From the user point of view, the package names are unchanged (except the source package and the binary package containing the sources) so no transition is needed.

138 Responses to “Debian is switching to EGLIBC”

  • This is excellent news, thanks Aurelien!

    Anything that makes glibc easier to manage for embedded purposes is very, very welcome. Even just having an embedded-friendly upstream is a huge bonus.

  • [...] tava mais do q na hora de alguém dar um pé na bunda do ulrich drepper: adoro o [...]

  • Michael says:

    > The EGLIBC is a variant of the GLIBC which stays source and binary
    > compatible with the original GLIBC.

    The website reads a bit differently: Retain API and ABI compatability with GLIBC wherever feasible.

    The “wherever feasible” part is, what makes me a bit nervous.
    I don’t think it would be a good idea to break compatibility with other distros.

  • Jon says:

    If the compatibility is correct, I think this is a great move. Cutting poisonous people out of F/OSS where possible is always good and wedging a buffer between you and them when it isn’t is a good second place.

  • Hector Oron says:

    Thanks Aurelien :-)
    This is a great improvement

  • Daniel says:

    Your post reminded me how did the glibc maintainer think their definition of UCS-2 is “more correct” than the one from, back in the late 1990s.

  • [...] nahrál balíčky Embedded GLIBC (EGLIBC). Ty právě čekají ve frontě a brzy v Debianu nahradí stávající GLIBC. Z pohledu uživatele se nic nemění, názvy balíků zůstávají stejné a GLIBC a EGLIBC jsou [...]

  • Sandeep says:

    will this be picked up by ubuntu eventually? any idea..

  • [...] talists: Personal Finance News from Yahoo! FinanceHyperMac External MacBook Powerreddit Debian is switching to EGLIBC The Haskell Platform is live! A single, standard Haskell distribution for every [...]

  • marky says:

    I hope ubuntu will pick it up, will be good serious testing before it will go to debian stable lol :D

  • rjc says:

    What does The GNU C Library Steering Committee say to Ulrich’s “dictatorship”/being difficult?
    Surely they can help, especially when one man’s decisions affect the most of the community.
    Had anyone contacted them in that matter?

  • [...] Interesting read, especially the ‘as opposed to this’ links. [...]

  • mike says:

    hey, you can perhaps ask those eglibc dudes to incorporate strlcat/strlcpy
    functions that are everywhere now, except the glibc.

  • thomas h. says:

    Would be nice to have for the __SOLE__ benefit alone of avoiding annoying and arrogant upstream.

  • Jason Wilder says:

    Wow, I think you brought up sme excellent points!


  • Samir Ben Abid says:

    Nice move!

  • RedChrom says:

    Who made this decision? Could you provide any link on discussion with other debian developers?

  • cate says:

    But copyright assignment to FSF is a very bad feature of EGLIBC: complex, slow, legal status not clear in most jurisdictions, and legally problematic: If I send a patch to the mailing list, without copyright assignment, I block your development on such topic: it would be legally difficult to prove that the new patch is not derived code (in legal world).

    FSF needs only few core files to be able to control relicensing and to oblige third party to accomplish to the (L)GPL.

  • DaGoodBoy says:

    Excellent! We say that developers who go all frothy during code reviews are “pulling a drepper” when they don’t listen to others.

  • [...] имеется ряд преимуществ, которые в Debian посчитали (см. достаточно важными для замены традиционной [...]

  • [...] here comes the next one; Debian just decided to replace glibc by eglibc, because the maintainer of glibc, Ulrich Drepper, is.. lets say very uncooperative when it comes to [...]

  • Ana says:


    This decision was made by the glibc maintainers.

    You can grep their mailing list to see if there is any discussion there, but a lot of stuff in Debian is discussed also in IRC and real life.

  • Greg says:

    Does this mean Debian will change its name from GNU/Linux to Embedded/Linux now?

  • [...] This post was Twitted by trm42 – [...]

  • mangoo says:

    Does it mean even greater incompatibility among Linux distributions? :(

  • Grant says:

    why do Linux people always need to hop from one flower to another? Isn’t stability more important than hurt feelings of some developers?

  • gus3 says:


    Click the links.

    When the hurt feelings and the associated arrogance turn into an incorrect final product, what’s the difference?

  • Eugeni says:

    The real question is: which will arrive first – EGLIBC or GNU/Hurd? :)

  • Alterax says:

    I’m not so sure if “stability” is preferable to running off fresh talent. Egomania–especially unchecked–kills off innovation among paid developers, and makes it nearly impossible for attracting and retaining volunteer talent.

  • Kens says:

    There really is no need for people like that Ulrich guy in friendly, open source communities (.. or anywhere for that matter), so I think it is a great move.

  • [...] ends of their tethers trying to deal with the foibles of GLIBC and its maintainer. There’s a post on Aurélien Jarno’s blog saying: I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is currently waiting in [...]

  • Ché Kristo says:

    I am amazed that Red Hat let that sort of behaviour fly…maybe it’s cultural but he comes across as abrupt and rude – not the sort of person I’d want representing my company in any public forum.

  • Anonymous says:

    This was bound to happen eventually. I’ve seen Drepper be a jerk way too many times. In fact, I’ve never ever seen him be nice.

  • When they won’t incorporate patches for the ARM platform, I think they have a larger problem. And when they start dictating how charactersets are meant to work to the prinicipal authors of the characterset definition, then they *definitely* have problems.

  • JR says:

    As for “stability > hurt feelings”; yeah, well, reporting a bug and being met by “Stop wasting people’s time! Nobody cares about this crap” doesn’t hold much promise about code viability in the long run.

  • [...] Aurelén Jarno zum Import der EGLIBC in das Debian-Paket-Repository [...]

  • Bluehole says:

    Hmmm… nice.
    It will make Embedded foot prints drastically low size.
    I hope it will always be in sync with glibc.

    second thought:
    will it replace uClibc???

  • [...] spezialisiert und zur Glibc weitesgehend kompatibel. Daneben sieht der Debian-Entwickler Aurélien Jarno noch weitere Vorteile, wie eine bessere Kommunikation innerhalb des [...]

  • fabiz says:

    news like this one leave me perplexed … how is it possible to change such a primary component of a system without hearing from community first ?
    in my opinion the community has the influence (or power if you want) to make changes happen.. i mean, if in Ulrich view there is only a “crap”, that means only that one person … i would prefer to see patches happen in the main glibc …
    Debian is so important, so important … really can we afford such a diverging move ? compatibility problems may arise, future contributions very probably will be only for glibc OR eglibc but NOT both…
    Are we sure we want this ?

    Opinions are welcome!!!

  • cutugno says:

    I think you really lost your mind this time. While I agree that Drepper is an arrogant asshole, and that losing a dicksize war to such an individual is quite not pleasant, breaking compatibility with all other distros (sorry, I’m too old to believe that “100% binary compatibility” crap) seems too big a price to pay for some minor bug fix on an insignificant platform.

  • Yellownohole says:

    Eglibc wont replace uClibc as uClibc has support for running on platforms without a MMU or even a MPU.

  • rjc says:


    It’s highly unlikely that it will replace uClibc.

    Start with EGLIBC FAQ if you haven’t done so yet.

  • rjc says:


    I’d also like to see all of that in Glibc but so far it seems unlikely.

    I don’t however share your fear concerning compatibility.
    Have you read anything about EGLIBC?
    I guess not.

  • Some remarks:

    - It is only natural to change a Library, or whatever, if there are advantages in doing so. Take the example the move from Xfree to X.
    As the API is the same, small adaptations may happen, but do not disturb that much the whole system. It is usually refreshing.

    - Just because some diferences do exist in the prespectives of diferent people… well, that’s only human. And thanks for the years of dedication in libraries we trust.

    - Also: Nobody is perfect and relations do erode with time. This is frequent and happened with all of us one time or another. That certainly no reason to transmutate one’s old hero in the new daemon in town.

    - Finally: Whatever faults one may have, I’m positive many qualities too. That is not the point. The point is a change was considered apropriate and that’s no reason to create a soap opera from the subject.

    I do remember a great programmer, the Zmodem creator. Not a nice fellow… but maybe because he was the the first victim of it’s dedication. Looking back, every user that transfered files between systems… gained tremendous beneficts from his work.

    I shall always be thankful for in spite of not using zmodem anymore. It was, and still is, an excelent transfer protocol, and a much needed one at the time. A big thank you for all the work invested in a tool for everybody to use. That is what is to be remembered!

    Dutra de Lacerda.

  • Marc Espie says:

    Hey, if you’re getting rid of Drepper, how about finally adding strlcpy and strlcat to eglibc, if they’re not already there ?

    In the past, Drepper has repeatedly said “real programmers don’t need those functions”.

    Well, my experience in OpenBSD is that actual real programmers don’t know how to count, and helping them by giving them string functions that are really hard to misuse is a very good idea. (countless advisories against strcpy, strncpy, strncat, which are all really easy to fuck up)

    as of now, Linux is about the only Unix-like left which does not ship strlcpy and strlcat as standard.

    heck, even the kernel has them…

  • fabiz says:


    ok, i think i’ve understood your position..

    yes, i’ve read something about eglibc… for now is a sort of “enhanced variant”.. not a diverging fork.. if things stay in these rails i’ve no fear too.

    Maybe i’ve looked too much at the bad side of the coin … ;)

  • [...] Linux distribution Debian is going to switch from GLIBC to EGLIBC according to the blog of Aurelien a Debian [...]

  • fabiz says:

    @Dutra de Lacerda

    the concern in my mind is only one.. behaviour.. in details and as a whole.. if we have the same behaviour i think we all are happy … welcome to enhances, welcome to improvements etc etc … but what if the behaviour change ?

    nevertheless i admit i may have too much pessimistic taste

  • Gweihir says:

    Actually I agree that strlcpy and strlcat are not an improvement. The issue here is that they improve the situation marginally only, but at the same time create additional risks, namely that of truncation and that of people not understanding that the problem has not really be fixed.

    Ulrich Drepper is right here: C is an inherently messed up programming environment, especially its laughable string and buffer handling. The fix is to not use C (or C strings) if it can be avoided. Personally, I use C only when performance is critical and then very carefully. For any other stuff, I use real languages (as opposed to high-performance, but stone-age tools) like Python or Eiffel. (Side note: Java is somehow stuck in between. I don’t like it either, but it is an improvement.)

    I am not saying C should go away. There are those performance critical things. I am saying C is an expert-only tool and needs to be handled with care. In many cases using it can be avoided completely today.

    And a comment on Ulrich’s style: He had that even at University. And, knowing him, I believe most of his technical decisions will be high-quality. However, he should by now have learned that you need to document the rationale for a decision carefully. There is no excuse for failing to do that. Only careful documentation will ensure things get better in the long run, as otherwise people that do not understand the decision, may later make matters worse again or revert the change outright. Only documentation of the rationale allows others to asses the quality of a decision. Expecting people to “mind-read” is unprofessional and petty. And in addition, a carefully documented _wrong_ decision can be fixed later far more easily. We do all make mistakes, even Ulrich.

    And a comment on large FOSS projects: It seems some maintainers get stuck in a siege mentality. It happened to Xfree. (And was dreadful, waiting a year to have them add the ID of new video-cards is unacceptable. I was running for long times with a self-compiled and hand-patched Xfree. And it was basically just adding one line.) Xfree was replaced with after enough people got fed up. It may be time for it happening to the glibc. A “don’t bother me” maintainer is unusable, no matter the technical merit of his work. A “read the documentation I wrote (find it here) and don’t bother me until you have” maintainer is a completely different thing.

  • roger says:

    Good stuff.

  • [...] A compatibilidade (com fontes e binários) deverá ser mantida, e os nomes de pacotes também serão mantidos (exceto os dos fontes). As razões da mudança (que não se restringe às arquiteturas embarcadas) foram sumarizadas em um post de um mantenedor do pacote no Debian. [...]

  • [...] This post was Twitted by openremote – [...]

  • el_es says:

    Hmm… why did you (I mean, those who have been put off by Ulrich) not try to contact whoever stands above him and explain your technical points there ?

  • el_es says:

    The glibc website maintains a list of people involved in glibc – a whole board of people that is – – could they do the right thing (TM) ?

  • [...] un breve mensaje en su blog, el desarrollador y mantenedor de paquetes del proyecto Debian Auréllian Jarno un [...]

  • [...] un breve mensaje en su blog, el desarrollador y mantenedor de paquetes del proyecto Debian Auréllian Jarno un [...]

  • [...] 070509 Debian is switching to EGLIBCI have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is currently waiting in the NEW [...]

  • Jack Ripoff says:

    Ulrich Drepper is a moron. He is keeping glibc in the past. About time someone forked the project and did something about it.

  • [...] Debian project isn’t happy with things either, and just a couple of days ago Aurélien Jarno announced initial moves to abandon glibc for the eglibc (Embedded GNU libc) code-base. This was quickly [...]

  • [...] Debian somehow decides to switch from glibc to eglibc. I thought Debian actually cared about transparency? [...]

  • Tiago Almeida says:

    I don’t like this, it would change anything for me and I fear losing compatibility with other distros, will there be a way to mantain GLIBC ?

  • Jan Wildeboer says:

    [Disclaimer - I work for Red Hat]

    Whatever Debian as a project decides is fine with me. But IMHO this is a move with quite some impact. Wouldn’t it be wise to base this decision on a more stable fundament by asking the Debian community for opinion?

    From a runtime environment perspective this switch might cause some problems for applications running on Debian. Wouldn’t it make sense to go through some thorough testing before the switch is finally done?

    Just my personal opinion, BTW.

    Jan Wildeboer

  • fabiz says:


    You went straight to the point, about C or not to C … moreover I think is not good that Debian (what might be considered the “reference” distribution of linux systems) is going in such a direction.. Debian will use eglibc… and the real reasons seems weak at the moment…

    What will happen then?.. RH also follow? SUSE will follow? the mythical Slackware will follow too?

    The real problem with Linux to the masses is the proliferation of divergence rather than convergence. Distributions, kernels, compilers, libraries.. it seems to me that we really still are at the geek/nerd/university level.. i’m wrong? if so please someone let me to the point. The feeling here is that we really need to have agreements rather than misunderstandings..

    It seems that this decision has been inspired more by grudge than technical reasons..

  • Maix says:

    I think most people here are completely unaware of the fact that currently all major distributions heavily patch glibc because the release just isn’t ready for primetime.
    So, using elibc instead could actually lead to more unification and make an end to this different patch-sets.

    (And and gcc have similar stories, turned out quite successful.)

  • flameproof says:

    MUTATIONS IN THE DNA OF GLIBC!!! Awesome = EVOLVE. Nice job, too! Leave that troglodyte in the dust scratching his fleas in his RHEL cave where he belongs. There’s really only ONE thing holding GNU/Linux back from being eaten whole by the masses (as it, like Solyent Green is, of course, PEOPLE), and it’s that thing which afflicts Ulrich and his ilk: ARROGANT GEEKISM. No one, absolutely NO ONE likes an arrogant, asshole-ish geek. Even other geeks (and you know someone over at RedHat is snickering in their cubicle right now). Good job, way to go and It’s About Freakin’ Time.

    As for strlcpy and strlcat; at lest the BSD guys’ll be happy now. Just be careful with that!

  • Ben Scherrey says:

    So who are the ultra-experienced, super dedicated, incredibly intelligent, (yet NICE) people or person that is replacing Drepper? Frankly the whining about him being a jerk doesn’t impress me at all since so many of these incidents resulted in Urlich keeping superfluous (or even worse) nonsense out of the library. I always see him pulling out some truly unanticipated insights that I doubt anyone in it as deep as him are capable of making so consistently. So he’s the Dr. House of the libc – get someone better or get over it. I just haven’t seen the “better” option identified yet and have very little confidence in it happening. I would love to be proven wrong but, meanwhile, I will avoid any distro using eglibc until the new maintainers have made some hard choices that impressed me. Just hope Ubuntu will stay away from it for now…

  • [...] andato a male? Come riportato da LWN e segnalato da drizzt in MessageBox (grazie!), Aurelien Jarno ha annunciato che Debian è passata da GLIBC ad Embedded GLIBC per una serie di motivi, tra [...]

  • haxxor says:

    please, contact redhat and try to find another solution, do not switch to another glibc… don’t destroy this binary compatibility between linux distros..

  • thebohemian says:

    “EGLIBC strives to be source and binary compatible with GLIBC.”

    eglibc = e + glibc

  • Gweihir says:

    Quite frankly, binary compatibility is overrated. I can’t even remember the last time I neded it between dirstros, if ever.

    Source code compatibility is something else. That is critical.

  • [...] andato a male? Come riportato da LWN e segnalato da drizzt in MessageBox (grazie!), Aurelien Jarno ha annunciato che Debian è passata da GLIBC ad Embedded GLIBC per una serie di motivi, tra [...]

  • worried_user says:

    What are the compatibility ramifications with this? What are the compatibility ramifications concerning other distros? I’m worried about my archlinux :(

  • Marc Espie says:

    Coming back to strlcpy…

    keep aside considerations about changing languages. A lot of people still program in C. A lot of people still make a huge number of mistakes in strcpy use. I still patch security holes away coming from misuse of these functions.

    Look at the code. I still see a huge amount of buffer overflows coming from strcpy/strlcat miscalculations.

    At least, strlcpy and strlcat don’t have those issues. And they make it really, really easy to check for truncation. Only a total moron can miscompute sizes using them.

    How about being practical, and starting by fixing real issues, instead of worrying about people thinking this is the end of it ?

    In my world, you start by fixing issues, instead of educating people (somewhat) and hoping the issues will go away.

    Sorry if I’m a bit annoying about it. I could really live without having to fix security holes each time I want to import software into OpenBSD’s ports tree…

  • Nix says:

    Ben Scherrey: there are a lot of binutils/GCC/toolchain hackers as competent to develop glibc as Ulrich is, and these are the sort of people who work on eglibc. C library development is not rocket science, not even dynamic linker development.

    In any case, eglibc is constantly synched with glibc and shares maybe 99% of its code: it’s more a ‘glibc with the added ability to apply patches without having to be one of a very short list of people allowed to apply patches without Ulrich’s say-so’ than a true fork.

  • Gweihir says:

    I do understand your situation. But the real issue here is people using tools that are too complicated for them. Sure, adding these two functions and then making people actually using them (no idea how you could) would cut down on buffer overflows. But people that cannot handle the old functions can very likely not handle C. They will just make other and possibly more subtle mistakes. The only real fix is to move them to tools that are much easier to handle.

    Of course there will always be those that vastly overestimate their own competence. There is no fix for this besides cleaning up after them, no matter how annoying it might be.

  • Bob says:

    From a runtime environment perspective this switch might cause some problems for applications running on Debian. Wouldn’t it make sense to go through some thorough testing before the switch is finally done?

    That is what Debian’s testing and unstable branches provide. Its not like they are instantly switching libC in the stable branch with no testing.

    As long as binary compatibility is maintained (e.g. nvidia.ko and the closed sourced applications continue to work as expected with eglibc) this shouldn’t matter too much to the end user and makes life easier for anyone working on crap.

  • Jamie Looky says:

    About time, I’d say. Maintainership should be by election, once every couple of years. And this not only for GLIBC, but for every big OSS project.

  • [...] Aurelien’s weblog และ Linux Hater’s [...]

  • [...] somehow decides to switch from glibc to eglibc. I thought Debian actually cared about transparency? [...]

  • [...] Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. Read the summary at or go directly to the source here [...]

  • DaVince says:

    After having read pretty much every comment in this blog post, I’ll have to go and say that I’ll have some confidence in the change to eglibc – Current versions of glibc seem to be already patched heavily and something like this would unify this kind of thing, there are people saying that other big projects had a succesful change like this before, and in the end it lowers the overall footprint and compatibility with more processor architectures.

    Just one question: what will be the benefit for the end USER, next to being able to use it on embedded systems? Will it be faster than current glibc? Will it make any apps using it oh so slightly faster?

  • Sslaxx says:

    Someone needs to open an “Ulrich is a jerk” bug… suggested fix? Removal.

  • Marc Espie says:

    I still think strlcpy and strlcat are a huge improvement, in general.
    It means people don’t have to do a lot of length computations, which means they can think about some other things, and then they have a chance to catch other mistakes.

    Making simple things as easy as possible is a very good first step in getting better code…

  • @fabiz

    A bit of unease is understandable, but hey! It’s Debian!

    On the other hand, the APIs are respected. What is changed is the implementation and it’s structure.
    (Unless anyone is hacking with side-effects that should not exist… then compilatition WIIL elliminate those suspicious side-efects. Nobody else would use what should not be there in the first place… that’s crackers territory).

    So the behaviour SHOULD BE the same.
    And it is a good chance to eliminate the mess of an history of patching over patching that and adapt solutions created by the OpenBSD project to be used as default option. That would help a lot of other libraries that depend on this one to get code security.

    This I speak a user as I never liked C. period.
    Always used Turbo-Pascal and ASM if needed.

    And, as a user, the chance to have code security (and eficience) added to the system security of nixes… (due to not so patched code and diferent structure) well, that is something even C developers should embrace as a promesse that will benefit everyone.

    My main rules were always the KISS rule and derivatives:
    – Keep it Simple, Small, Clean (well structured) and Fast !

    Unfortunatly when something evolves, it gets away from those rules.
    Just look at windows code. But they listened and are cleanning the house.
    We warned them… why wont we listen ourselfs?
    Why do we started following M$ mistakes? It was easier?

    Well… A good clean design (I’m not sure it is the case) is always harder at first but easier later. And the opposite, the start fast and easy approach always created huge problems for latter. That’s why you have sometimes to rewrite everything from scratch.

    I suppose (please someone confirm) that now somebody had done that for you… to get the beneficts of a different approach… with the very same APIs… That’s why expect it to be refreshing!

    I still do not like C BTW, but let it be smaller, simpler, faster and safe… And everybody will be extremelly happy after an adaptation that is supposed to be quick and painless.

    After all…It’s Debian! (And that means the inner details you trust)

    Dutra de Lacerda.

  • tinkertim says:

    I think this is a great move. Ulrich can be rather difficult. I don’t think he means to be intentionally hostile or abrasive, he’s just very blunt. Maintaining glibc (for him) is a burden, he’s made that quite clear in the past.

    I’d also love a platform where I can use native glibc for appliances, without the hassles of cross compiling against a foreign C library such as uclibc. I love uclibc, but I’d much rather use something binary compatible with glibc on appliances. It gives users more choices and us (the developers) more flexibility when designing them.

    It would be really, really cool if the base OS install for such devices was just a debootstrap away, without having to fiddle with the basics.

  • [...] A compatibilidade (com fontes e binários) deverá ser mantida, e os nomes de pacotes também serão mantidos (exceto os dos fontes). As razões da mudança (que não se restringe às arquiteturas embarcadas) foram sumarizadas em um post de um mantenedor do pacote no Debian. [...]

  • Woody says:

    Hi, I’m a Debian user. This is a decision related to a critical component and could have big consequences. Could this issue be submitted to votation? Thank you very much.

    Best regards

  • [...] stap over naar EGLIBC By eislon Volgens de Blog van Aurelien , een Debian ontwikkelaar, stapt de Linux distributie Debian over van GLIBC naar [...]

  • [...] the codes? The attitude/conflict is about the coding and bug handling. See the links in the blog …. particularly those linked to ‘as opposed to this’ at _This is sources Bugzilla_ Lotsa spats [...]

  • [...] va a sustituir la librería de C de GNU, GLIBC por la Embedded GLIBC (EGLIBC). Al parecer los motivos son sobre todo una mayor apertura y [...]

  • [...] LWN me he encontrado este blog, donde cuentan como Debian va a subir a sus archivos una libc alternativa optimizada para sistemas [...]

  • I_hate_debian_and_hate_you says:

    Ulrich Drepper keeps doing a very good job. Those assholes could go fsck themselves because the issue was solved before they even reported it. They should first check if it works with current before a bugreport.

    I hate Debian, so my system is Gentoo. I’ll stay with glibc and If elibc suddenly becomes incompatible in a way my program will run everywhere, but on Debian, I won’t fix anything. Debian is braindead piece of crap which is already too much incompatible with a normal GNU/Linux distribution, such as Slackware or Gentoo, and this makes it even worse.

  • [...] Unix-like operating system, and for Debian to switch from the well-established Glibc is big news. This blog post explains the reasons behind the move to EGLIBC, noting technical aspects such as a consistent [...]

  • [...] recently announced a switch from GLIBC to EGLIBC, the embedded optimized version of GLIBC. Aurelien’s blog post lists the reasons for [...]

  • phonixor says:

    not all of the post in those bugtracker are his, cause some don’t have his redhat address… still he has some rude posts…

  • [...] han tenido problemas “políticos” con un responsable técnico de la librería libc y los han “solucionado” pasándose a otra librería denominada eglibc, si a esto le sumamos la libc del sistema Android empiezas a sospechar que probablemente te falten [...]

  • DaVince says:

    Well! Some people sure hate others.

  • [...] it came to me that Debian is going to switch to EGBLIC [...]

  • bero says:

    Thanks for making this move! Over at Ark Linux, we’ve been thinking of doing the same thing for the same reasons for a while — the primary thing holding us back was diverging too much from the core system of the big distributions.

    Now that one of them has actually made the same decision, we’ll follow in the next couple of days.

  • Okonomiyaki says:

    The advantages out-weigh the disadvantages..
    I don’t know why so many people are scared and think that debian will suddenly turn to a broken pile of crap just because of this..
    There is a reason debian is known so much for it’s stability..
    If eglibc were to cause any problems, of course debian is going to fix it.. And after the transition, debian will have all of those advantages listed..

    Let’s say you have an old television, but thinking of getting a newer high-definition wide-screen television..
    Some one else might tell you “But that might break compatibility with our other stuff!”
    Well, what do you do then? Just stick with your old television which is a piece of crap?
    Yeah at first you might have some compatibility problems, but as soon as you fix those, look how much cooler your television will be!

    Just like our lives and minds, open-source coding and programs constantly change..
    The small changes happen all the time, but every once in a while, it is also time to shed some bigger things in light of newer most efficient things, just as we shed xfree for x, among other things..
    So things will always be replaced, and in the far future linux distrobutions will look radically different from how they do today, simply because it evolves..

    All this is is a shedding and transition of some thing that has worked for a long time, but now might no longer be the best thing to use..
    Some thing like linux should not play favorites..
    If some thing else works better, then why not use it instead?..
    Hell, who knows, in the future the hurd kernel might actually finally finish some century and blow linux away, but if it is tons better, why not use it?.. (Although right now hurd still sucks a big dong)

    Even the standard file-system ext3 and ext4 might be replaced now with btrfs soon.. Why? Because it is tons better in every single way..

    So after the dust settles, debian will be a slightly-improved debian..

  • [...] that Debian is switching to eglibc, nothing is holding us back, and the eglibc 2.10 package is currently making its way through the [...]

  • King Neckbeard says:

    >I hate Debian, so my system is Gentoo.

    Cool story bro.

  • [...] Informations sur le blog d’Aurélien Jarno : [...]

  • [...] Debian is switching to EGLIBC (tags: glibc debian) [...]

  • [...] not very well known outside of the embedded space, but that looks to be changing with the announcement that Debian will switch from glibc to EGLIBC. This article (subscribers only) takes a look at [...]

  • [...] not very well known outside of the embedded space, but that looks to be changing with the announcement that Debian will switch from glibc to EGLIBC. This article (subscribers only) takes a look at [...]

  • migus says:

    bravo :)

  • Le Glaude says:

    As modern CPU are tuned to deal with 64 bits alignement, how wants a glibc compiled with -Os ???? Posix compliantness of both Glibc and Applications is a more important deal, do you realize that modern architecture don’t fly to embedded ??? I don’t want to sacrifice stability and compatibilty, so you want less bytes used by your system ??? more free ram ???? Gnome and Kde are the bloatwarez to move around, not the glibc ….

  • This sounds like great news, to me. I see people complaining about the lack of transparency, but my experience as a Debian devloper is that the people who are likely to have a good technical understanding of the issues involved *will* have been consulted. Technical decisions should not be subjected to a vote, as someone suggests above, and Debian does not do that.

    The fact that such a decision can be made by a small group of interested, knowledgeable and capable people is *exactly* a strength of Debian. The fact that the rest of us can come along and notice after the fact means that I did not have to waste my own time trying to understand the issues, and can concentrate on doing the things that I do.

    And if, as some suggest above, the maintenance of glibc is becoming burdensome to Ulrich Drepper, then the decision is probably even welcomed by him also, as it could lead to a significant reduction in his own workload and allow him to be less grumpy on projects which fewer people care about.

    If nothing else this seems to provide a public and centralised location for sharing a standard Glibc patchset, giving them greater transparency and discussion, but I believe it provides a lot more advantages than just that, and I can see few disadvantages indeed.

  • Steve Parker says:

    “do we really need NIS or RPC support in debian-installer?”

    I am working on what looks to become a large scale GNU/Linux rollout for one of the UK’s larger supermarkets. They do need NIS support. As well as a lot of other features provided by the existing infrastructure. DNS, NTP and the like are no problem at all. NIS and PAM, and their ilk, are less easy to integrate with a shop used to Windows and UNIX, but not Linux.

    To answer the question directly, we are not assuming that NIS is available during the installation process, but we do make use of the fact that the (RHEL KickStart) installer does allow for configuration as a NIS client.

    As it happens, Debian is not on the radar for this project; at some level, GNU/Linux needs support for these features if it is to work with this infrastructure.

  • [...] is even more friendly, cooperative, and socially well-adapted than a certain OpenBSD maintainer. illustrates this [...]

  • [...] Flash from Adobe, but this time I had problems. I’m not sure if it’s because Debian has switched to EGLIBC or what, but I was getting errors from the script installer saying that my version of GLIBC [...]

  • [...] Che si possa biforcare un progetto per “discordia” fa ridere. Sembra incredibile e, soprattutto, infantile, ma non si tratta di casi isolati. L’ultima, in ordine di tempo, è stata l’accesa diatriba fra gli sviluppatori di Debian e il maintainer della libreria glibc, che si è rifiutato di accettare una patch per farla funzionare con le architetture ARM (definite “crap“, sposando in pieno lo stile di Torvalds), e che ha costretto i primi a crearne un clone. [...]

  • Soinnaemere says:

    Sweet blog. I never know what I am going to come across next. I think you should do more posting as you have some pretty intelligent stuff to say.

    I’ll be watching you . :)

  • blah says:

    I can’t believe that Debian would actually risk fragmenting the very core of many Linux distributions over a pissing contest with Ulrich Drepper. Do you even realize what you’re doing? Do you know how much of a compatibility nightmare this is going to be? How the fuck do you expect to draw commercial developers and companies to Linux when they’re now going to have to support two different versions of the _C LIBRARY?_

    This reeks of irresponsibility on both sides, it’s disgusting that this is going on and the potential damage it could do to linux adoption is enormous…but apparently Debian doesn’t care.

  • [...] nahrál balíčky Embedded GLIBC (EGLIBC). Ty právě čekají ve frontě a brzy v Debianu nahradí stávající GLIBC. Z pohledu uživatele se nic nemění, názvy balíků zůstávají stejné a GLIBC a EGLIBC jsou [...]

  • [...] muito conhecida fora do círculo dos dispositivos embarcados, mas parece que isso vai mudar com o anúncio de que o Debian vai mudar da glibc para a [...]

  • Anonymous says:

    Fuck! Shit! it’s time to drop Debian…

  • FK says:

    Fuck! Shit! It’s time to drop Debian…

  • Tony Reix says:


    I’ve just discovered this switch from glibc to eglibc (I no more work in Linux world. Now back to AIX since 3 years).

    I fought some years ago with this ugly ass-hole egocentric Ulrich Drepper when I proposed him to incorporate into the glibc our PTT (Posix Thread Tracing Tool) tool designed for tracing the NPTL routines. Around 24 p.m of work. Previously I develop a POSIX thread test suite that found some problems in NPTL.


    Read what I said this morning to a guy asking if PTT is still alive:

    The project PTT has reached its goals:
    1) have a high quality and very good performance,
    2) has nearly no performance impact when not used, and
    2) be ready to be integrated by the libc guys.

    However, the maintainers of the glibc (including Ulrich Drepper) were non-professional guys at that time: they refused to integrate our work (me + 5 students, about 24 p.m of work) in the glibc.

    The reason ?
    1) These guys thought that their wonderful code had no bug….
    2) They never worked in the real world and they never understood how important it is for the end-users/customers to be able to capture
    information about why things does not run as we expect they should. And any non-stupid guy knows that programs never work as we expect they should.
    3) They refused to integrate code they didn’t write (understand that no one can write so marvelous code as they do…).
    4) They didn’t want to have some more code to maintain (understand that they would had to spend some time to read code they didn’t write).

    Now that Ulrich Drepper works for RedHat, I guess he has learned a
    little bit more about the debug/tracing needs of customers: RAS (Reliability, Availability, Serviceability). However, I think that such an ass-hole guy can never change his mind since he is so egocentric.

    I see that this (bad) guy has a Wikipedia entry. I’ll add some nice
    comments one of these days.

    If Linux kernel does not plan to include more trace/debug tools, Linux will never be a professional tool. I mean that, for big critical
    projects, customers require to have tools to capture failures at the
    time they appear or to be able to capture data for understanding what happens.
    I now work again in the AIX world and I see how important it is for our customers to be able to capture failures.

    So you are free to get the source and port it to the last version of
    I think that my students provided enough documentation to help people to port it easily, though you must spend time to understand how NPTL works. If you plan to do that, you may ask Guillaume if he can provide you with advice.


    Senior AIX System Management Architect

  • Tony says:

    I’ve updated the French version of Drepper Wikipedia, so that the information about the transition of Debian from glibc to eglibc does appear.
    I’ve also added a note in English and French version of Wikipedia about the fact that Ulrich Drepper refused to add any tracing tool for the NPTL thread library, though several people asked me during the last 3 years why PTT is not part of the glibc.

    BTW, if you think that such a tracing tool would be useful for eglibc, go and take it. Everything were done to make the adding of PTT to the glibc as easy as possible.
    Working now in the AIX world, I see how important it is for our customers to be able to trace AIX components.

  • Tony says:

    I’ve also updated the NPTL Wikipedia entry, in order to give information about the PTT tool and about he OPTS (Open POSIX Test Suite) tool for testing NPTL against the POSIX standards.
    Sébasitien Decugis, who worked under my direction at Bull SAS, spent a lot of time for implementing OPTS, which provides conformance, functional, and stress testing, with main focus on Threads, Clocks & Timers, Signals, Message Queues, and Semaphores.
    OPTS can help you to check that eglibc works fine. We found several problems in NPTL with it.

  • [...] has been roughly one year since Debian has switched from GLIBC to EGLIBC, so it’s probably the time to make a small report about this [...]

  • [...] switch from GLIBC to EGLIBC affected functionality of some software like Skype for a few hours, but I [...]

  • [...] que ya tendría que haber finalizado la migración de glibc a eglibc, otra de las novedades que nos contaba Auréllian Jarno en su blog, y la introducción de Startup, la variante nueva del sistema de inicio basada en el [...]

  • [...] Jarno, Aurelien. Debian is switching to EGLIBC. (May 5, 2009). Aurelien’s weblog. Retrieved October 9, [...]

  • [...] Jarno“在 blog 上发表了一文<Debian is switching to EGLIBC>,文中宣告了 Debian 将会逐渐使用<EGLIBC(Embedded GLIBC)>取代 GLIBC(GNU C [...]

  • [...] is even more friendly, cooperative, and socially well-adapted than a certain OpenBSD maintainer. illustrates this [...]

  • [...] is even more friendly, cooperative, and socially well-adapted than a certain OpenBSD maintainer. illustrates this [...]

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>