[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Mint patches
On Sat, 05 Apr 2008 11:15:46 , Vincent Rivière <vincent.riviere@freesbee.fr> wrote:
> 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 incompatibiliti
> es
> > caused by the two compilers. Will there be any problems or am I worryin
> g
> > 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.
>
Thanks Vincent it's good to see the latest situation. I understand most
of the issues but can't really contribute.
I was thinking ahead to what might be done once a release of GCC 4 is
ready.
Regards,
Peter