[Fedora-packaging] Re: Cross-compiling guidelines

[Ralf Corsepius]

On Wed, 2007-05-02 at 16:46 +0000, Kevin Kofler wrote:
> Rex Dieter <rdieter <at> math.unl.edu> writes:
> > http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers
> 

> Another open question is: what does "targetname" have to include, in particular 
> for non-GNU toolchains? Does it have to be a full target triplet, 
Generally speaking, the "targetname" needs to be sufficiently "unique"
to identify the target. 

In practice, this means it needs to supported by config.sub, which is
supposed to return the correct target triplet when being invoked with a
"target_alias"[1].

> e.g. "m68k-ti-tigcc"?
TIGCC is problematic, but helping you here would require to look into
your sources (see below).

>  (But "avr-" already isn't...)
Well, I know and consider this to be a design flaw. avr-elf would have
been better ... (see below)

>  Otherwise, what parts are 
> required? Is the CPU required (e.g. "m68k-tigcc")? Or would installing 
> to "/usr/tigcc" be OK? My personal opinion is that any target name which 
> uniquely identifies the target is OK, if that's just "avr" or "tigcc", that's 
> OK, if it needs more components (e.g. "i386-rtems4.7" 
> vs. "someothercpu-rtems4.7" or "i386-someotheros"), then these are required.
OK, some background about the target triplet:

>From a user's side, each target is identified by a target-id-string
(often called target-alias), e.g. i386-rtems4.7

Inside of autoconf based configurations (e.g. in binutils, GCC, gdb)
each target-alias is expanded into a target-triplet (by config.sub and
config.guess[1]), consisting of _exactly: 3 fields separated by "-"
delimiters (often referred to as arch-vendor-os)

Each of these target triplets must be sufficiently unique.

The traditional definition of the target triplet had been:
ARCHITECTURE-MANUFACTURER-OS
with
ARCHITECTURE ... target architecture
MANUFACTURER ... target HW manufacturer
OS ... target OS
e.g.
sparc-sun-sunos4.2


This applied well to the situation when the target-triplet had been
introduced, but this definition has evolved (some say abused):

* The definition of ARCHITECTURE is not clear and leaves a lot of room
for interpretation (Is an x86_64 an i386? Is i386 a family?)
Nowadays, toolchain vendors set it to what meets their demands best.

* HW manufacturers have mushroomed, so tying a particular toolchain to a
particular HW manufacturer had been found to be impractical
(i386-delldimension5100-fedora?). 

This resulted into "MANUFACTURER" having hardly been used in useful ways
anywhere and simply being carried around. Linux vendors started to use
it to put their brand into it (*-redhat-*), most other vendors simply
"don't use it" (i.e. are using the implict default" - in most cases:
"unknown").

* With regard to OS, the problem occurred that OSes (esp. Linux) have
changed in incompatible ways. Toolchain suppliers had to find ways to
reflect such changes into the target triplet to sufficiently denote such
incompatibilties. The OS field had been found to be the most practical
approach and nowadays is widely used for this purpose.

Typical changes of this kind had been:
- Changing the object format (Linux: a.out -> coff -> elf)
- Changing libc (Linux: libc4 -> libc5 -> libc6 (aka glibc6))
- API changes (RTEMS: rtems<osversion>, Solaris: solaris<osversion>)
- Political/branding issues ("Linux" vs. Linux/GNU, 
  "SunOS" vs. "Solaris")
- OS variants (Linux: e.g. uclinux)
- Alternative libcs (Linux: newlib vs. glibc.)
Esp. on Linux this all had resulted into a pretty large series of
"canonicalization triplet" changes over the years.


This all is more or less without any impact on normal users, except for
one situation: Cross compilation.

GNU conventions are use "target-alias"-prefixed binaries for
cross-compilation to allow installation of several toolchains in
parallel and mixing native and cross compilation in one package.

Somewhat oversimplified, autoconf uses the rule "if --host and --build
are different, then a package is being cross compiled" (=> search from
"host-alias"-prefixed tools instead of non-prefixed tools, e.g. search
for "m68k-rtems4.8-gcc" instead of "gcc")


Back to your questions:
- avr: Using a target alias of "avr" is sufficient at this point in
time, because its toolchain doesn't have a sufficiently long history for
a need for more. The situation the avr is in is not unique for new
targets, but I consider this to be a typical beginner's fault, they'll
probably regret in longer terms. 

- tigcc: I don't know. If I understand correctly, your tigcc is a fork
from GCC. I.e. it can use any arbitrary target-alias as long as its
binaries' names do not clash with GCC. If they can clash, you must use
different target-identifiers. If tigcc is a standard GCC with "some
architectures" having been added which are not present in the FSF's GCC,
then you can chose whatever you find appropriate, because its binaries
can't clash with those of the FSF's GCC.
If its a "value added/extended GCC", the least risky approach would be
best to use <architecture>-ti-<OS> (i.e. to set "vendor"). 
The even better approach would be to have your changes integrated into
upstream (FSF-GCC).

Ralf

[1] config.sub expands a target-alias into a full target-triplet using a
couple of "implicit conventions" having accumulated over time (have a
look into it for details).
e.g. 
# ./config.sub avr-rtems4.8
avr-unknown-rtems4.8
# ./config.sub avr
avr-unknown-none

(autoconf) configure scripts and GCC internally use the full
target-triplet and individual fields of the triplet.