Re: [MiNT] large binaries with MiNTLib 0.55.2

[Tomas Berndtsson <tomas@nocrew.org>]

"Guido Flohr" <gufl0000@stud.uni-sb.de> writes:

> Currently the only use for debugging information is that you can
> use the program addr2line to calculate a source line number from
> a crash dump as given by the MiNT kernel.  Andreas Baer is working
> on Paral to make it evaluate the debugging information too, so that
> you can do source level debugging with Paral.

No chance of getting gdb ported?

> OK, but even the symbol table left apart, new binaries have grown. 
> That's true.   Why? Try to run the test suite of the MiNTLib 0.55.2
> with older MiNTLib versions.  You will see that more than 50 %
> (if not most of them) will fail with older versions.  The string 
> functions weren't 8 bit clean, printf and friends were hopelessly 
> buggy resp. outdated, floating point support was buggy and only
> partially integrated.  When you debugged software you often ended
> up with a MiNTLib bug, too often.  A lot of complex functions had
> been illegally simplified in old MiNTLib versions, and of course
> this saved space but I suspect that these simplifications and bugs
> were the reason for a lot of instabilities and these arbitrary
> crashes that we all know.

I see. Well, I won't complain then. :) I got that feeling too, when
comparing some of the headers from 0.53 and 0.55.2, that they look a
lot more like glibc now, which is usually a good thing for porting
programs. 

> But the actual problem is not that the MiNTLib has increased in
> size.  The problem is the absence of shared libraries under MiNT.
> However, to implement the tools necessary for shared lib support
> you need a stable libc.

Yes, I agree. I haven't followed the SLB discussion here very closely,
but I agree MiNT would really improve with shared libs.


Tomas