p.slegg@scubadivers.co.uk wrote :
Also, with GCC4 not too far away I was wondering how the transition might be managed. For instance, should the current RPMs be frozen and new ones created ? This would minimise problems of incompatibilitiescaused by the two compilers. Will there be any problems or am I worrying aboutnothing ?
Hello.I think the first thing to do is to stabilize the MiNTLib. Especially the issues with the preliminary stack: it has been "fixed" with a workaround, but never really understood. There is also an issue with gets() with pure TOS: it freezes in an infinite loop. I posted a patch for that monthes ago. And also, it would be nice to make it compilable with the cross GCC 4.3.0 without any warning. Then the MiNTLib may be ready for new release GCC 4 friendly ? This step is the most important, because that MiNTLib will be embedded with the new native tools.
Then it should be possible to build a reliable RPM for binutils 2.18 with either the native GCC 2.95 or the cross GCC 4.3.0. Jean-François reported an incomplete strip with the -s option, maybe it has been fixed by the latest MiNTLib patch from Alan. I also saw once some garbage at the end of an executable produced by ld, but unfortunately I'm not able to reproduce this problem again. Maybe it was the same problem ? I also found recently a little issue: when using --tradiditonal-format (DRI) the cross ld produces invalid endian values for the *debug* symbols __stksize and __heapbase. I think it is harmless, and I plan to fix it soon. Apart of this little issue, the cross and native ld 2.18 produces the very same files... really good news. Some weeks ago, I reverted all my experimental alignement features from the binutils 2.18, so now they should behave exactly as the binutils 2.13. An upgrade from binutils 2.13 to binutils 2.18 should be totally transparent and harmless.
Then for compiling a native GCC 4.3.0, we have fist to compile the GMP libary. Keith reported a successful compilation, but a failure in the unit tests. This issue must be investigated before going further, because it may result in bad code generation with GCC !
So there still a lot of work... I hope we will manage to get some concrete results. -- Vincent Rivière