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.