Retiring from uClibc development

[Peter S. Mazinger]

On Mon, 3 Apr 2006 sjhill at realitydiluted.com wrote:

> > If you would have really cared to follow, then you would have seen, that 
> > the commits were grouped around a number of functions. I have taken some 
> > functions, removed the jump relocations for them and committed them as a 
> > "unit". I have surely overseen some of them due to the many possible 
> > configuration combos, that had to be corrected later on.
> > 
> I did follow, and tried to. My builds broke everytime I tried to do
> a merge and stay current with trunk. All of your relocation stuff,
> and I mean all of it should have been checked in at once, not in
> pieces. It took you a couple of months to get all of that stuff
> working, but yet you checked stuff in little by little over those
> two months breaking things here and there when you should have waited
> and then asked for someone to test your stuff. You still don't get it.
> 
> -Steve

Then you are not getting something else, the "hidden" commits haven't 
broken svn, it could have broken your branch, because you have not gotten 
all the parts of my commits. Those function "units" were enough tested for 
an "unreleased" version, because I ran them live.
The "hidden" stuff affected libc runtime, staying w/ one or more 
relocation until they were hidden later was not affecting builds. The only 
issue that is "hidden" related is that I haven't counted w/ a 
gcc/binutils/arch version dependency 
(this was solved by having an uClibc_arch_features.h)

The breakages that I can recall were caused by:
a. switching from x() and __x() pairs to "hidden", when it became obvious 
that it is better for uClibc (even allowing you to disable all that in one 
central file) and not use it at all, if you derised to)
b. removing visible __x (that we agreed upon), but some of them were 
used "visibly" in the macro-called-by-macro-called-by-macro stuff 
mentioned in some other post (or remember __mempcpy)
c. not having access to all possible/supported archs (thus not catching 
all the needed changes for all, after vapier set up the test suites, this 
became a non-issue), did anyone offer any archs for testing? Gentoo gave 
me access, so that I could test in chroots (on arm/ppc/x86, mipsel being 
broken, unrelated to "hidden")
d. adding all the proper headers to source files that were missing them, 
correctly prototyping, that was almost completely missing from earlier 
uClibc (or the prototype had another meaning of a function as it's 
definition) and it broke x() and x64() pairs, depending on archs having 
some syscall or not. I think for now almost all are "good" within libc (I 
recall only getdents remaining that IMA compile reported as faulty, I 
have asked on ml about this one, but noone answered). The linuxthreads* 
stuff suffers also by "unproper" prototyping, but gcc is unable to report 
the real cause when structures are out of sync.
e. differences between compilers, I used gcc-3.4.4/5 for testing, you used 
at that time an unreleased gcc4.
f. strong v. weak (have you ever answered one of my related mails on ml)?
This is also the main cause for most of the current breakage w/ 
cross-compilers, and not the "hidden" stuff.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2