Re: [avr-gcc-list] How to use pgmspace.h in a library source without warning?

[Georg-Johann Lay]

Weddington, Eric schrieb:
> > -----Original Message----- From: Georg-Johann Lay 
> > [mailto:address@hidden Sent: Saturday, June 08, 2013 6:36 AM To: 
> > Weddington, Eric Cc: Thomas D. Dean; address@hidden 
> > Subject: Re: [avr-gcc-list] How to use pgmspace.h in a library 
> > source without warning?
> >
> > Weddington, Eric wrote:
> >
> > > computers get faster every year
> > Computers don't get faster.
> >
> > It's just the case that the not-so-fast computers are declared as 
> > scrap, and thrown away an then replaced by a-bit-faster computers; 
> > again and again and again...
>
> Pedantically, yes. That's what I was referring to.
>
> > I don't think that things should get more complicated and more 
> > resource gulping -- in the contrary: things should get easier to 
> > grasp and to handle and to understand.
>
> In a way, lib/device would actually be simpler then lib/arch. When a 
> user compiles a program, they compile it for a specific device, not 
> an architecture. Then the library for the architecture gets linked 
> in.
>
> The only thing that I see that gets complicated is transitioning from
>  one style to the other, and then the increase in compilation.

Just perform the following 2 steps:

1) Make AVR-LibC adopt avr-gcc's multilib layout.
   Currently, we have

$ avr-gcc -print-multi-lib
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@msp8
avr25/tiny-stack;@address@hidden

2) Change avr-gcc's multilib layout to whatever you want.
   Notice that this fixes #35407 (add tiny-stack multilibs).

> Again, I see it being offset by being able to build on newer, faster 
> computers and by building in parallel. Will it be completely offset? 
> No, of course not. But then we can really design libraries to be 
> specific to devices and get rid of some of the kludges and 
> compromises that are in there in building it per arch.

we just had the request to (effectively) raise -Os to a multilib option. 
 That way the libraries can be tailored for small code or for fast code.

And there was the request to raise -f[no-]short-double to a multilib 
option so that double can be 32 or 64 bits wide.

That would flood us with ~800 multilibs. Arrgh.

Johann