I don't know the internals of glibc and looking at the glibc ebuild in portage it seemed like it would be a good idea to had this down to bugzilla instead of tackling it myself. Reproducible: Always
Switching entire system to this lib even without reemerging world seems to be viable and useful in some cases. We have also some news about EGLIBC from Debian maintainer: http://blog.aurel32.net/?p=47. EGLIBC is based on and is binary compatible with GLIBC now, so no much severities of supporting systems based on different libs are going to do.
yes Debian provided good reasons to switch to it.
I'm sincerely _not_ sure that all the reasons provided by Debian, at least on Planet Debian, are that good. Half of them seems to be "you don't have to deal with Drepper" (although I guess that's going to be a good advantage for some people at least). Not really going to be extremely easy to support though, so _huge_ amount of work is needed.
(In reply to comment #3) Thank you for your answer. > I'm sincerely _not_ sure that all the reasons provided by Debian, at least on > Planet Debian, are that good. Half of them seems to be "you don't have to deal > with Drepper" (although I guess that's going to be a good advantage for some > people at least). It looks quite odd when library developer (OK, libc developer; right, very talented developer) is dictating which shell must be used to bootstrap this library and changing behaviour of such important code without any justification and discussion. > Not really going to be extremely easy to support though, so _huge_ amount of > work is needed. Please could you explain your point? EGLIBC has almost the same code as GLIBC, at least at present time. Debian and Ubuntu teams are able to test virtually all existing software with new library, so you don't need to do all the work from scratch. Gentoo developers use patches from other distribution, so that's OK to switch to the new library together (I don't mean full switching, just supporting it as yet another usual configuration; it must be possible to switch the working system even without re-emerging world now). Personally, I'm waiting for Fedora maintainers to do such report too. They are well known experimentators, they even didn't afraid to build their new release with GCC 4.4... You probably have an impression that I'm agitating for EGLIBC, but I'm not. I just wonder is it possible to switch or not.
I sincerely doubt Fedora would ever consider this given they write the paycheck for Ulrich. It's not like I like him, but he's usually manageable.. with the due blunt force. I don't disagree with the fact his methods would need to be watered down, I don't think that deciding to _change the C library_ of a whole project is something that should be done _just_ for him. It's not even the case of Jórg Schilling and his redistribution-mess with the code. I have other interest in eglibc which exhumes from Drepper, and I really think that _in that respect_, eglibc is a perfectly valid alternative. On the other hand, I wouldn't want to switch to that on my main desktop anyway. Note that this is, anyway, just a personal consideration. I'm not saying that the project is not interesting, I'm just saying that I don't see any _enormous_ advantage that would warrant such an effort _right now and immediately_. As for relying even slightly on Debian/Ubuntu testing. I won't. Ever. Found way too much crap that slipped through the two of them, so no I'm not going to accept that they did the work already. Also, they didn't, we have packages that they don't have (and sometimes the opposite is true). As for not rebuilding the system, I wouldn't suggest that anyway. If we're going to support eglibc, it's going to be a different profile, with different stages, which means different testing. Even if they are virtually the same right now, I wouldn't trust them to be _the absolute same_, now or never. Starting from their own modularity: it is good, it's just not going to make it always a drop-in replacement. Given I have experience with Gentoo/FreeBSD, replacing the C library in the system is not going to be fun or simple.
(In reply to comment #5) > I have other interest in eglibc which exhumes from Drepper, and I really think > that _in that respect_, eglibc is a perfectly valid alternative. On the other > hand, I wouldn't want to switch to that on my main desktop anyway. I got your point. But could you tell something about possibility for eglibc to get official support in Gentoo on one level with GNU libc? Are any special procedures needed to make this decision? Is there any probability that they will be started in the foreseeable? I see full support of new library requires twice work on testing, patching, staging, making images for download. What do you think are Gentoo developers ready to go there? Will they be ready in future when let us say eblibc will get significant advantages over GNU libc? My questions seem to be quite naive, but yet...
FWIW http://blog.flameeyes.eu/2009/05/07/a-new-c-library is where I dumped my concerns and comments about eglibc for now, just for reference.
This article: http://lwn.net/Articles/333755/ points out that EGLIBC is not a fork of glibc but rather a distribution of it and should be fully compatible. EGLIBC also adds "option groups" which should be welcome in the Gentoo community as this feature enables more ways of customization (on the other hand this could lead to a dependency hell) and could be worth a try in the long term - perfect for Embedded Gentoo.
I have several Freescale e500 based systems with Gentoo on them, so I'm forced to use eglibc, as its the only one with hardware floating-point support on this platform. My finding so far are as following: 1. glibc ebuilds can be used with eglibc, given the later is repackaged the same way as glibc 2. glibc ebuilds are quite complex and have all kinds of name dependencies, so the simplest thing for me was to create an ebuild called "glibc-2.10e" which pulled eglibc tarball in 3. glibc eclass is overly conservative in regards to CFLAGS and strips some important ones, -mfloat-gprs being a good example Given that, I hope some progress can be done on adding eglibc to the portage, as there are platforms which depend solely on it.
I believe that I have a *very* rough start of an eglibc ebuild, based heavily off of the standard glibc ebuild. It has zero testing and throws a few QA warnings... but it is building on my system presently. I have a Portage overlay at http://www.valleyhold.org/~gordons/gentoo - please bear in mind that it's mostly one-off hacks or applying patches for bugs I've seen here - but I'm keeping my eglibc work there. If people don't think that it's utter crap (i.e., it shows some promise of being useful someday) I'd be happy to move it to someplace where others could take a crack at it.
Is there an interested Gentoo developer with who we may team up to add EGLIBC support to Gentoo? I'm one of EGLIBC developers and have enough experience in that area, but I have very little experience with Gentoo. Joining efforts with a Gentoo developer we should be able to put together EGLIBC support for Gentoo.
i dont really have time available to support both sys-libs/glibc and sys-libs/eglibc. when you guys switching to git ?
(In reply to comment #12) > i dont really have time available to support both sys-libs/glibc and > sys-libs/eglibc. Well, I guess we'll have to drop support for sys-libs/glibc then :). Speaking seriously, at this point I'm interested in a rough estimate of what it would take to *implement* sys-libs/eglibc, not necessarily a commitment to supporting it. I would prefer to take it a small step at a time, if people start using EGLIBC in Gentoo and find it more appealing then GLIBC, then we can consider where to go from there. > when you guys switching to git ? I get this question a lot, I wonder why? So far we are comfortable with svn, no immediate plans to switch to git.
Well, I'm very interested in making it go... the problem is that I am not a Gentoo developer per se, but a developer who happens to use Gentoo. :) I have an ebuild which can successfully build and install eglibc, but it does not "play nice" with the rest of Portage... for instance, other ebuilds make calls to "has_version glibc" which fail. It would make sense to me for eglibc to still use "ELIBC=glibc", as they should be compatible. For the immediate moment I'm not too concerned with ebuilds checking for eglibc's options.def flags - if you're using a custom configuration for eglibc, autotools should usually notice the changes, and if a particular package breaks then you should submit an ebuild patch. But I'm not sure how to resolve the has_version issue - would every ebuild need to check for both glibc and eglibc? Should this get abstracted to a function and then changed everywhere?
two major reasons: (1) glibc itself is using git, thus merging/branching off of the official tree is infinitely easier than svn. reviewing some of the svn commits, it seems like svn isnt working nearly as smoothly as you guys are running custom scripts to "merge" commits and keep things in sync. it'd be helluva lot easier with a tool that actually supports merging. (2) find any "why distributed scms are better than non-distributed scms" article. having everything at your finger tips without needing the network is infinitely smoother. this comes from personal years of experience maintaining large projects (like the linux kernel and u-boot) in cvs, then svn, then git. cvs->svn is like a god send, and svn->git is like kratos -- surprisingly epic for a spartan. pessimistically, what it's going to take to get eglibc into Gentoo is me sitting down and doing it. the first step would almost certainly not support any of the conditional build -- you'd only get what glibc offers. optimistically, i'd be a lot more inclined to support eglibc if the upstream merging policy were better than glibc's. i constantly get c-blocked by drepper for no technically good reason. trivial examples off the top of my head: http://sourceware.org/ml/libc-alpha/2006-08/msg00008.html http://sources.redhat.com/bugzilla/show_bug.cgi?id=9685 http://sourceware.org/ml/libc-alpha/2009-12/msg00010.html http://sources.redhat.com/bugzilla/show_bug.cgi?id=11929 which leads to me keeping a huge retarded pile of patches.
As far as the conditional build stuff, the ebuild I put together does have rough support for it, in the same fashion as ucLibc. That is to say, it is not done "right" via USE flags, but you are able to provide an complete options file, and it will use it. Also like ucLibc, I'm not too concerned about making other packages "detect" a custom-built eglibc; if the package breaks with your build, then submit a patch to that project so that its configure script works properly. (I've gone through this more than once with ucLibc.) If you can give me some pointers to what would need to be done, I may be willing to work on that (may, because it depends on what my work schedule ends up looking like).
Is there something new regarding this topic? The URL http://www.valleyhold.org/~gordons/gentoo results in a 404 error, so there seems to be no ebuild or overlay with eglibc right now.
(In reply to comment #17) > Is there something new regarding this topic? The URL > http://www.valleyhold.org/~gordons/gentoo results in a 404 error, so there > seems to be no ebuild or overlay with eglibc right now. Sorry about that - I reorganized some stuff on my server, and finally got my Portage stuff into a Git repo. You can get to it now at http://www.valleyhold.org/git/gitweb.cgi?p=gentoo-portage.git in a browser, or git://www.valleyhold.org/gentoo-portage.git via Git.
I created an old one for exherbo here: eglibc-2.12.exheres-0 - http://dpaste.com/589589/ eglibc.exlib - http://dpaste.com/589591/ The problem with eglibc (or what seemed to be the problem) is that different 'suboptions' (features) broke the install process.
with upstream glibc revitalized, i don't see much point in eglibc anymore. the work should be focused on merging the two bases again.
