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