[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Proposal: cross-compiling / development packaging guidelines

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
  * 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
  * 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
  * 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.


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

   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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]