Carmelo, Not to be disrespectful, but I agree with Rob's assessment. I too have been using the uclibc library for more than 5 years and it's releases are few and far between compared to many other open source projects.
I have seen at least 3 other branches of uclibc being maintained by other people outside the official repositories because of the slow or non-existent response from the uclibc developers. The fact that the nptl branch is still not in the main branch is in my opinion a lack of vision from the maintainers of the project. The nptl code is needed in order to compile any recent version of VLC for example. Recently, I spent over 60 hours of work using multiple machines to perform simultaneous compilations trying to get the nptl branch working on x386. Unfortunately, I had to stop because the solution to the problem was beyond my skillset. I am able to do some coding and prepare patches for simple things and offered my time to test anything that needed to be tested to no avail. I also reported an application crash that happens with the 0.9.30.1 and newer libc malloc code and that was not there in 0.9.28. I could not find a solution for it. The developers of the app swear that it is a bug in the ulibc libraries and the uclibc developers say those types of changes of behavior and normal and expected and that it is the application doing something wrong (even though it is exactly the same application source code in both cases). My point is, has the target user of the uclibc changed since its conception? Are you guys only focusing on big companies that develop embedded devices? It would explain why there is still no support for 386 on the nptl branch. Is there someone within the uclibc developer organization maintaining the priorities of the limited developer resources? If so, can those be communicated to the user community through the web site so that we can all make an informed decision whether to continue using the library? Embedded storage has become larger and larger recently and the standard glibc library is no longer an outrageous choice. If it is a matter of resources, why don't you post a message on your web site asking for help. I am sure there are hundreds of qualified individuals that can help with the project. Regards, -- Sergio M. Ammirata, Ph.D. On 11/22/09 8:02 AM, "Carmelo Amoroso" <[email protected]> wrote: > Rob Landley wrote: > [SNIP] >> Currently, it's not clear _which_ branch a development release would come >> from, and thus what would be worth testing. The nptl branch? The >> inexplicable other development branch which NPTL still hasn't been merged >> into >> more than 3 years after the OLS presentation on NPTL for uClibc? The merge >> of >> these two branches has been "in progress" since Erik was maintainer, but I've >> never even seen an -rc containing NPTL code. >> > > Hi Rob, > > it happens periodically that you post your concerns > against the NPTL merge and so on, and it is becoming to be a bit irritating, > I'm sorry to say this. > > Steve, Khem, myself and recently Austin have done a lot of effort in this > direction > (plus obviously Mike, Bernhard and other guys), but this is not an easy job, > and I guess a lot of us are busy with a lot of other jobs in the linux world > beside > uClibc. > > For example, we @ST, are working to provide prelink feature into uClibc, > that is something I think being really important for embedded system where > performance > and fast-boot are becoming to be a pressing needs... > and this task is consuming time that we cannot spend in the merge... so I > don't care > about merge currently. > > But let me say that, even not merged, the NPTL branch for those supported > archs, > it's a reality, production ready, embedded C library (a lot of really big ST > customers > in the Set-top-box world are already using uClibc on sh4 using all the work > we've done > in this year). > > So, please, if you want to contribute to this project, please take actions and > send patches... but do not periodically complain against the work that other > guys > are not doing, because they don't have enough free time. > > I'm sure you will understand my point. > > Regards, > Carmelo > >> >> Rob > > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
