On Wednesday 04 February 2009 20:55:28, Danny Backx wrote: > We have the same goal. >
> But if nobody assembles the bits and pieces and turns them into > something that's ready to use, then acceptance and use will be lower > than they could be. True. > > In the past, a lot of effort has gone into getting stuff to work. The > time this took has made us lag behind gcc/binutils/gdb/mingw. We must > not do this again. It's very simple to update binutils to a more recent version. But, there simply isn't much there that we'd benefic from. Of interest, I can only think of the recent addition of a new version of pseudo relocs. Updating mingw isn't so simple as binutils, as we do have many local changes, but it's indeed doable. I think I'll go update those. > > Pedro has already done the right thing for gdb. I've gotten one fix into > binutils. > > My push recently was exactly meant to do what you want : for us to use > something more modern so we can focus on fixing problems upstream. > > We had a harder time doing that in the past. I think we lacked > experience at that time. Maybe also stability. > Anyway : I've just compiled binutils 2.19. It took three trivial > configuration file changes to get a full compile. I'll try to get them > submitted. I don't think there's much to push, except for a patch that makes us default to armv4. Guys, please let's get one idea off of our heads. For PE targets, there isn't much benefit in sticking to the point binutils releases. It you go looks at cygwin or mingw binutils releases, you'll find that most have been based on some random snapshot. Actually, importing a point release into our trunk instead of a snapshot makes it harder to work with. snapshots or cvs checkouts have a different contents from the releases; the releases often miss a few things useful to our development. > The bootstrap gcc build failed because gcc/gcc/config/arm/pe-stubs.c > wasn't present. Copied it from the other tree. After that, the bootstrap > build succeeds. Great. Now we only need to fix that properly. > The next thing to fail is mingw. I'm not sure whether I want to invest > in that given your remarks on mingw-w64. Is your experience that it can > replace the src/mingw in the cegcc tree ? I'm sorry, I can only read this with a sense that there's confusion on what are our local changes, and the relation between these trees. I'm hoping you don't actually believe that you only have to replace one component for the other and things will magically work. -- Pedro Alves ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
