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]

Re: crosstool-0.40 released: gcc-4.1 rc1 support


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]