[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.