This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Dan, On Mon, Feb 20, 2006 at 07:36:36PM -0800, Dan Kegel wrote: > Well, it's been six months and several releases of gcc since > crosstool-0.38 was released -- well past time for another release of > crosstool. This one adds in some nice bits sent in by users and adds > support for gcc-4.0.2 and gcc-4.1 rc1. I'd like to bring out > crosstool-0.41 when the next rc of gcc-4.1 is released, so please let > me know what I missed, and I'll try to add it. That's good news! I'd like to take this for a reason to hear about your further plans with crosstool. We've yesterday discussed which current problems we have at Pengutronix with what crosstool provides. Things are pressing more and more, so we'll have to decide how to proceed with the toolchain building mechanisms for the future. So I'd like to hear your position on these topics. Our main focus is on Linux toolchains, so see this just as some public thinking from our point of view, no offense or whatever intended. I'm only interested in your oppinion. - The whole "add-more-little-unkomfortable-scripts" mechanics sucks, as well as the spagetti code style of the main scripts. There are no well defined interfaces between the building blocks (passing stuff by environment variables is simply plain uggly). The question is how to address this: when we talked about the uClibc stuff some time ago you sayed that you'd like to see this integrated in a more function- or several-scripts-like method. - We really need NPTL support for our toolchains now. Crosstool's NPTL activiy has stuck, there is not more serious support for it in 0.40 than there was in 0.38, which is roughly half a year old. Modern systems, for example with Preempt-RT need NPTL, so we need a roadmap how to get support for it. - We really need uClibc, not now, but in the near future. The patches we currently have in PTXdist against crosstool are not maintainable. - Softfloat on ARM isn't solved. - Managing out-of-tree patches against crosstool is a mayor pain in the You-Know-What. So what we currently do in PTXdist to support features which fix crosstool problems cannot be handled any more. - I'm not sure what is your intention of supporting _all_ gcc/glibc/... versions out there, and I doubt that this is maintainable. There are the gcc major versions: 2.95 3.3 3.4 4.0 4.1 4.2 Always combinded with the latest glibc (2.3.6). IMHO a toolchain build script shouldn't encourage people to use stuff from the past - the patch mess is clearly visible. When things for 3.3.1 have been fixed in 3.3.6, why still provide 3.3.1? If somebody needs it, he can use an old crosstool which supports it. What's the reason behind just being able to say that even old versions from a line can be made working just by applying a can of patches? The maintainance burden is immense for the situation as it is now, and in fact the codebase shows that even you cannot really handle it any more. - The development process is not open enough. We are usually working very closely together with upstream people, and in fact PTXdist is mainly about making upstream better by supplying the relevant patches. People don't have a chance to jump on your train when you only release every half a year. It doesn't make sense to send you intrusive patches against six month old codebase without knowing what you have internally. We are now in a situation where we have to decide which way to go. I'd like to stay with the crosstool project - in the end Open Source is only successful when it has critical mass, and crosstool has. So any kind of fork would be bad, because it results in community splitup. Here's my proposal for what I would like to see: 1) I've opened a crosstool project on Berlios, which is here: http://developer.berlios.de/projects/crosstool/ It has public SVN, which would be the main feature, as website and mailinglist are fine the way they are. We could open a "Dan's Maintainance Trunk" which can hold exactly what you do at the moment, without intrusion by others, but visible to the public even between releases. 2) I'd like to see some public discussion about how the main crosstool scripts have to be structured. That probably means clean interfaces, separated scripts or functions, config frontend. The svn on berlios would give us the possibility to make a prototype for that in a branch, without disturbing your work, and involve people from the community. Would you accept such a procedure? It does only make sense if you'd really use it. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |