Proposal: cross-compiling / development packaging guidelines

[Hans de Goede]

Hi All,

As you all know by now I'm working as a computer science teacher on a Dutch
university. In a few our lab exercises we use Atmel AVR microcontroller kits
and I'm working on a lab using the gp2x handheld console (ARM linux machine).

Currently the AVR labs are given using winavr, running on that other OS. I
and a couple other teachers are interested in also having a toolchain for AVR
available under Linux and I also would like to see a toochain for the gp2x
under Linux.

Thus we have given a group of 3 students the assignment to create
high quality rpm packages of binutils gcc and the needed libs for Fedora to
allow crosscompiling to Atmel AVR / ARM Linux on Fedora. I'm personally
coaching these students and unless they want to go through the sponsor
process themsleves, I will submit the resulting packages for review myself and
maintain them in the future.

Now that the setting of all this is clear on to the more interesting stuff
how should cross-devel packages for Fedora look? Proposal:

1) binutils, gcc, glibc and other libraries for avr / arm-linux will use the
    exact same upstream version as the native versions where-ever possible

2) All package names will be prefixed with the same prefix as binutils and
    gcc use, examples:
    avr-binutils, avr-gcc, arm-linux-binutils, arm-linux-gcc, arm-linux-glibc

3) The as,ld and gcc binaries:
   * will be named avr-as, avr-ld and avr-gcc resp arm-linux-as, arm-linux-ld
     arm-linux-gcc
   * will be installed under /usr/bin
   * will have links called as, ld and gcc installed under /usr/avr/bin resp
     /usr/arm-linux/bin. More on these dirs below

4) libraries respectively headers will be installed under /usr/avr/lib resp
   /usr/avr/include for avr and under /usr/arm-linux/lib resp
   /usr/arm-linux/include for arm-linux. I know this doesn't seem FHS
   compliant, still I believe this is the right way, rationale:
   * These path's are advised in the cross-compiler guidelines in gcc's INSTALL
     document
   * All cross-compile setup howto's / docs on the internet I could find use
     path's like this. IOW: "The compiling environments are well defined
     already, established in the standards, there is absolutely no compelling
     reason to move it to something Fedora specific."
   * We (Fedora/RH) have done this before with the libc5-compat stuff under
     /usr/i386-linux-libc5/{lib,include}
   * Quoting the FHS on this: "No large package (such as TeX and GNU Emacs)
     should use a direct subdirectory of /usr.  Instead, there should be a
     subdirectory within /usr/lib (or /usr/local/lib if it was installed
     completely locally) for the purpose.  An exception is made for the X
     Window System because of considerable precedent and widely-accepted
     practice.". I think using /usr/avr / /usr/arm-linux is ok with this
     paragraph as:
     1) a cross-compile setup is not a single large package
     2) Just like the X Window System (which we've moved out of its own dir
        BTW), there is "considerable precedent and widely-accepted practice."
   * Doing things like this is also where Debian ended up after ample discussion
     see: http://lists.debian.org/debian-policy/1999/04/msg00015.html
     Notice that today (7 years later) Debian is still doing things this way!

5) Docs (manpages, info and docs under %doc) will not be installed as they
    will be identical to the native version docs, instead a readme.fedora will
    be installed through %doc redirecting people to the native docs, and
    informing them what native package to install to get the docs if not
    installed already. So for example when people look under
    /use/share/doc/arm-linux-SDL-devel-%{version} they will find a readme.fedora
    redirecting them to
    /usr/share/doc/SDL-devel-%{version} and be told that if that dir does not
    exist that they then should install SDL-devel.


Problems:

7) With the arm-linux target some libraries may have target specific compile
    options, for example the gp2x handheld uses a special version of SDL with
    patches to support the gp2x input buttons and video.

    Proposed solution:
    a) install headers and libs for special platforms/targets under their own
       dir, for gp2x that would be /usr/arm-linux-gp2x/{lib,include}
    b) and then create binutils and gcc wrappers called special-prefix-binname,
       for example arm-linux-gp2x-gcc, these wrappers add
       /usr/arm-linux-gp2x/{lib,include} to the beginning of the lib /
       /include search paths and add flags for the cpu-type and other
       hardware specifics. These wrappers would be put in a package called
       gp2x-devel, which besides containing these wrappers would also Requires:
       all the necesarry bits, so that someone who wants todo gp2x development
       can just do a "yum install gp2x-devel" and get started.


8) The SRPMS for all these packages will most of the time contain the exact
    same tarbals as the native binutils / gcc / libs

    Possible solutions:
    a) Live with the extra diskspace / bandwidth cost this induces upon
       our mirrors
    b) *** Warning dirty hack ***
       Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep
       and if it isn't there bail with a message howto get the tarbal from the
       srpms for the native packages. We can use the sources file and the
       look-aside cache to make the test for the tarbal succeed on the
       buildsys. Advantages: saves tons of diskspace. Disadvantage: slight
       inconvienience for people trying to rebuild the srpm's manually. Large
       inconvienience for people doing automated rebuilds (aurora for
       example)

    I honestly don't know what todo here. I kinda like solution b), except
    for the pain it causes to aurora and possible others.


Well thats it (for know) I'm sure when we start actually building these
packages new issues will arive but first lets all agree on howto handle the
issues discussed above.

Talking about all agreeing on this, if there are enough people interested I
would like to start an embedded / cross-compiling Fedora SIG, any takers?

Regards,

Hans