fedora for generic crosscompile
Manas Saksena
msaksena at marvell.com
Thu Jun 7 17:54:47 UTC 2007
Andy Green wrote:
> Brendan Conoboy wrote:
>> Ed Swierk wrote:
>>> That said, there is certainly room for both approaches, and getting
>>> even a small number of packages to cross-compile might be enough for
>>> many embedded applications.
>> Definitely. For cross compilation, I picture a per-package flag in Koji
>> that marks it as cross-friendly or not. There are certainly numerous
>> technical and social details to work out to making such a system work
>> and work equitably. We're just getting started.
>
> Well some areas to think about
>
> - The disparity in platform resources and power will be greater than
> ever before. Choices made in ./configure switches that are the standard
> Fedora way can easily blow packages and dependencies out of scope for
> otherwise capable targets. You can tie choices in configuration to the
> arch, but isn't it more interesting to imagine it is its own "bloat
> dimension", so weak x86 targets can be built for? How about being able
> to specify multiple %build and Requires based on a new macro %_bloat.
> %_bloat = 10 is the normal supported Fedora traditional build with
> Kerberos everywhere and so on. But the spec file can also define
> alternatives along the lines of %if %_bloat < 10 <alternative config
> args> %endif or %switch/%case (either requires a little extension to rpm
> AFAIK). Only the default bloat level needs to be supported and shipped
> by Fedora to the extent it already is, folks can --rebuild to target
> lesser platforms fedgentoo style. %_bloat=1 can even give you a busybox
> / uClibc based result if you want to max it out. But to get started all
> the packages can just build the standard way without any conditionals.
While using a bloat dimension is interesting, I think it is too
difficult to capture the full richness of feature/footprint tradeoffs
using a single parameter like that.
Instead, the way I think this could be addressed is by:
-- providing a tool that makes it easy to rebuild packages with
different configure flags
-- make it easy for folks downstream to fedora to rebuild fedora
packages and fedora based custom distros using the above too.
-- make it easy for folks downstream to fedora to track upstream fedora
changes, while maintaining local
In my experience, this kind of customization is best done when the
feature/footprint tradeoffs are well-understood; i.e., when a root file
system is being created for a specific device, and when both the
functions to be supported by the device and the footprint constraints
are well-understood.
Over time, you could see a bunch of sample device profiles -- each
representing a customized root file system that is derived from fedora
packages, but in a systematic, easy, and traceable manner. And, these
can then become the basis of new device profiles.
You might want to take a look at "tsrpm" tool that was built by Chris
Faylor (ex TimeSys) that allowed some of this for Fedora RPM packages
using a mechanism called package hints. You can find more information
at: https://crossdev.timesys.com/ (the site is pretty much dead, but
there is useful information there). I have also cc'ed Chris.
> - How to install foreign arch libs and -devel packages. There is
> already a precedent in having i386 libs on x86_64 boxes but this is a
> bit different because the arch is REALLY foreign. It will have to know
> to do some kind of --root= action if it sees you installing s390 libs
> into an i386 box, because you clearly don't want them going into the
> real /lib.
This is handled by tsrpm as well (among a number of other nifty features).
Manas
More information about the fedora-devel-list
mailing list