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

[Paul Wratt <paul.wratt@gmail.com>]

On Thu, Jun 10, 2010 at 3:55 AM, Mark Duckworth
<mduckworth@atari-source.org> wrote:
> On 6/9/10 12:48 PM, Vincent Rivičre wrote:
>>
>> 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.
>>
> I definitely see it as prudent to enforce gcc 4.x compatibility with all
> sparemint packages but at the same time provide gcc 2.95.3 as a non-default
> compiler for user use.  That should make all parties happy I think.
>
> Thanks,
> Mark
>

This is the crux (atm), and this is the better result.

I agree with Vincent and Keith (and others) about using the latest
GCC, it makes sense.

I would then build a multi-gcc setup that would be acceptable to many
other as well, as this would be available on an ARFOS based LiveCD
that contains a full development environment (a bootable dev kit)

So I will presume that any gcc installed on my system will be the
latest for that distro.

When EasyMiNT is updated I will presume that it too will have a latest gcc.

It sounds like gcc-2 (or gcc2) would be ok in this system, and usable
when needed (is there a preference to naming convention)

My only real concern are the associated libraries that may be gcc
version dependant.

If that is not an issue, then it make things simple. Is there a case
where this might be an issue with an older gcc (2).

Obviously it is not a priority for 2.95 to have Coldfire capabilities,
but should be added at some point, if for no other reason than that
there may be a situation where it is the only answer (for whatever
reason?)

I will keep the above in the back of my mind as I build a bootable dev
kit, as well as the other comments made .. thanks for the info ...


Cheers

Paul