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

[Vincent Rivière <vincent.riviere@freesbee.fr>]

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