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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
