[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Mint patches



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 incompatibilities
caused by the two compilers. Will there be any problems or am I worrying about
nothing ?
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