[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Get rid of libc_g.a
On Tue, 2011-02-01 at 13:59 +0100, Vincent Rivire wrote:
> Miro Kropek wrote:
> > Great. You know what the cause was? Missing lib_g.a since '-g' was used
> > in default CFLAGs. People, common, is there at least *one* person who
> > loves to use debug/profile builds of mintlib along with 'g' and 'pg'
> > switches? Why on earth we need this stupid behavior?
>
> Good catch, this is a classic one.
> You forgot to install libc_g.a.
>
> Excellent transition, this issue was the next one on my list.
>
> Remember the problem: when you link with -g, your program will be linked
> with libc_g.a (the debug MiNTLib) which has the following features :
> - compiled for 68000 CPU
> - unoptimized code, to ease debugging
> - additional debug information, for debugging the MiNTLib at source level.
>
> This behavior seems to be quite nonstandard.
> It is a problem because most GNU packages are linked by default with -g,
> which on MiNT has the side effect to produce unoptimized or wrong
> executables.
>
> Someone told me recently that this libc_g.a was useless.
> First, it requires to have the MiNTLib sources to be exploitable.
> Second, in the rare case where someone really wants to trace the MiNTLib
> with GDB, he can compile a debug version himself, and explicitly link
> with it.
>
> Basically, this libc_g behavior has the following drawbacks:
> - nonstandard
> - useless
> - can produce bad executables if -g is used by mistake
> - can make trouble to configure scripts it not installed.
> Advantages:
> - none
>
> So I second MiKRO and I propose you, people, to get rid of that libc_g
> oddity.
>
> Furthermore, the profile library libc_p suffers about the same issues. I
> have never built or used gprof myself, so I can't tell if that one is
> useful or not.
>
> Comments welcome.
Agreed.
Alan.