sdcc - Cross Compiler, Needs Packaging Standards?

[Ralf Corsepius]

On Sat, 2007-02-24 at 20:09 +0100, Hans de Goede wrote:
> 
> Ralf Corsepius wrote:
> >>> This is why I plea for a cross-compiler SIG, so far I know of the
> >>> following people being interested:
> >>>
> >>> Hans de Goede   (avr-gcc, arm-linux-gp2x-gcc)
> >>> Kevin Kofler    (tigcc)
> >>> Ralf Corsepius  (rtems)
> > .. freebsd, cygwin, mingw ...
> > 
> 
> So does this mean we can count you in? (I think we can, but you never
> explicitly said yes).
For the moment, yes. But given the feedback, toolchains I had submitted
for FE more than a year ago had received, my expectations hardly could
be lower.

> >>> Welcome aboard, notice that I've got a couple of last-year CS students
> >>> working on packaging avr-gcc, so please contact me before things get
> >>> done twice.
> > 
> > Do me a favor, don't name cross tools "cpu", use a more specific name,
> > such as avr-elf. "avr" is too unspecific to specify a particular
> > toolchain, which, gnerally speaking, will always consists of more than
> > just a "target" compiler.
> > 
> 
> The avr is a 8 bit OS less mcu, the avr-gcc chain generates code to run
> directly on the bare hardware. There is no "executuble" format,
elf

>  no OS,
avr-libc

> no nothing.

elf/avr-libc alone cause this toolchain to contain hardcoded
characteristics, which make it unusable for other avr-targets
environments (e.g. avr-rtems uses newlib instead of avr-libc).

>  Also notice that every makefile for AVR software under the
> sun (that I know of) refers to avr-gcc as avr-gcc and nothing else.
Sorry, to me these packages are simply bugged.

> Thus for exact the same reasons why we want
> /usr/<target>/{bin,lib,include} and not seperate <target> dirs under bin
> lib include, we want avr-gcc to be just plain avr-gcc. 
This is a common fault, "bare" target toolchain implementors tend to
commit. They think a "cpu" is sufficient to describe a target-toolchains
characteristic. They miss that "cpu" alone means nothing and will break
when something changes, e.g. the object format, or the libc they are
using.

E.g. "i386" means nothing, a i386-pc-coff toolchains is something
completely different than a today's  i386-pc-linux toolchain (currently
implies i386/glibc2/elf.), a i386-cygwin toolchain, a i386-mingw
toolchain, i386-rtems or a "bare/freestanding i386" toolchain.

Ralf