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

Re: [MiNT] MiNTLib 0.59.1 for your testing pleasure....



Keith Scroggins wrote:
I would be surprised if all of those packages would fail to build in GCC4. Others can speak to this more than I can, but there is not a huge compatibility gap, unless there is assembly in the code.

The incompatibilities are:

1) As Keith said, inline assembly has to be revisited. It is only present in very low-level packages, and the job has already been done in the MiNTLib, GemLib, FreeMiNT... So I'm sure there is not much inline assembly remaining in the packages.

2) The aggressive strict aliasing optimization enabled by default. This causes compile time warnings and sometimes bugs. If bugs are encountered, we can turn off that optimization manually with -fno-strict-aliasing and see if things improves. Then fix the source of the bug with the help of the warnings.

I don't know anything else. These 2 kind of fixes will improve the code quality, the sources will remain compatible with GCC 2.x.

Also, all the GNU/Linux packages have been fixed for GCC 4.x long ago, so the updated packages should compile out of the box. Alan can give us his experience on Gentoo. The big problem is the obsolescence of the MiNTLib/fdlibm versus Linux's GLIBC, but this is unrelated to GCC itself.

However, there is still an important bug with GCC 4.x: the debug info produced in STABS format is often invalid. This cause GDB 5.x crashing or saying "cannot set breakpoint" or so on. GDB 7.x only produces a warning, but I have not finished porting it. Since this bug is specific to the obsolete a.out code generation in GCC, we can be sure no official developer would look at it. However, I have not fully investigated that issue, neither posted a bug report.

--
Vincent Rivière