Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden [mailto:avr-
> address@hidden On Behalf Of Joerg
> Wunsch
> Sent: Wednesday, September 05, 2012 2:05 AM
> To: address@hidden
> Subject: Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags
> 
> In article <address@hidden> you write:
> 
> >If you introduce a compatibility check then any usage of libgcc or
> >AVR-Libc will trigger a diagnose because these libraries are build
> >with the default ABI and none of these options is a multilib option.
> 
> Which, in turn, I think would be a really good idea. ;-)
> 
> I always thought specifying that -ffoobar nonsense is a poor idea from
> the beginning: "char", "signed char", and "unsigned char" must never
> be mixed in portable code anyway, so the code should work the same
> regardless of any -f option.  (For small integer numbers rather than
> printable characters, using C99 uint8_t/int8_t is much preferrable.)
> Short enums should be declared by the respective attribute rather than
> implying them by a compiler option.  Structure packing is a no-op on
> the AVR as it only requires an 8-bit alignment for everything anyway.
> 
> So yes, I think encoding them in the object format, and make the
> linker warn about mixing differently encoded object modules is a nice
> idea.  

It's a nice idea, but is it a solution looking for a problem? We haven't had 
any (to my knowledge) issues reported about users linking together incompatible 
modules. For the most part, an application is built altogether at the same 
time, using the same compiler flags. Rarely do one set of modules, compiled 
with one set of compiler flags, get linked to another set of modules, compiled 
with a different, incompatible set of compiler flags.

Let's make sure we're solving real problems, rather than made-up ones. If we 
start including those compiler flags, where does it end? How many should we 
include and check for?

Eric Weddington