crosstool and .rpm's (was: [distcc] Bootable distcc node)

Ralf Corsepius corsepiu@faw.uni-ulm.de
Tue Jul 27 14:56:00 GMT 2004


On Tue, 2004-07-27 at 07:00, Dan Kegel wrote:
> In http://lists.samba.org/archive/distcc/2004q1/002167.html, Dag Wieers wrote:
> >>By the way, since there are so many combinations of processor, gcc version,
> >>and glibc version, it would be hard to build all the RPMs for those
> >>combinations.  ...
> > 
> > True. But there's no need to compile all combinations and RPM may help in 
> > building for different architectures too. ...
> > 
> >>If you're supporting a stable of engineers working on the same
> >>project, it's worth building the combinations you need once
> >>(possibly as an RPM, if that's how your site likes things).
> >>
> >>But Fedora probably wouldn't want to include all the possible
> >>RPMs my script can spit out.
> >>This is a case where package managers have a bit of
> >>a disadvantage compared to an engineer downloading the build script
> >>from http://kegel.com/crosstool and just building the damn thing themselves.
> > 
> > I respectfully disagree. I see what you mean, but even Source 
> > RPM packages are very handy to build for different targets with different 
> > options from a single source. So even when I wouldn't have the combination 
> > some engineer need, I guess if crafted good, a single SRPM would suffice.
> > 
> > So when I find the time I'm going to look into your tool and see how I can 
> > take advantage of it as I've been always interested in providing this.
> 
> OK, I'm finally adding RPM support to crosstool.  I'm starting
> with the spec file contributed by Charlie Brady,
> http://kegel.com/crosstool/current/contrib/crosstool-mipsel.spec
> and am parameterizing it; all.sh will fill in e.g. the
> version numbers for the tools in use.
> I'm probably going to stop short of generating .srpm's; generating
> working .rpm's is enough for me for the moment (so the .spec
> files I generate will be completely bogus except for the
> %files section and whatever is needed to get that to work).
> 
> (I still don't know how to
> make a single .SRPM for multiple targets, though.
It's darn complicated ;)

>From my experience (I am the author of the RTEMS cross toolchain
rpm-specs), if you really want to provide a single SRPM, you probably
will have to resort to passing the target via rpm-defines
(rpmbuild --define 'xtarget xxxx').

For RTEMS cross-toolchains (They are newlib based and not based on your
crosstools package), I went a different way and am generating individual
specs for each target, using auto*tool-magic and  am using nosrc.rpms
instead of src.rpms.

> "What Does RPM Do To Make Multi-Platform Packaging Easier" at
> http://www.rpm.org/max-rpm/ch-rpm-multi.html talks about
> rpm's multi-platform features; they might help for handling multiple
> build systems, but provide no help for multiple targets.)
Exactly this outlines two-leaf Canadian Crosses (build != host).
(We (www.rtems.org) build RTEMS cross-toolchains for Cygwin under linux
using linux->Cygwin and linux->RTEMS cross toolchains and rpm).

Ralf



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com



More information about the crossgcc mailing list