fedora for ARM

[Andy Green]

Manas Saksena wrote:
> Andy Green wrote:
>> Hans de Goede wrote:

>>> Native compiling definitively is the way to go, an alternative might be
>>> emulating the native system and building in the emulated system.
>>
>> The way to go IMO is to improve the common packages to work well with
>> crosscompile... ones with recent autoblah on them generally work nice
>> and easily.  Fedora itself could do with say being able to build all the
>> arch binaries simply on a single build host too.
> 
> I agree; IMHO, this is the way to go in the long-term. As I see it, the
> first step is to make sure that rpmbuild and the Fedora spec file do not
> come in the way. That is, if an upstream package will cross-compile,
> then it should be possible to cross-build the corresponding Fedora RPM.
> 
> One might even look at it as a bug (albeit, at this point in time, a low
> priority one) if a package cannot cross-compile. Over time, it is not
> unreasonable to believe that this could be addressed through a set of
> diligent package maintainers and good packaging guidelines.

Absolutely, many upstream projects would no doubt accept small patches
or autotools update requests if it was coming as part of a Fedora
initiative, since everyone would benefit from it.  Any Fedora box being
able to be a build farm for all arches would be a great place to end up.

>> I have rpm-packaged a bunch of apps for crosscompile (arm9 and avr32)
>> here

> Did you have to modify rpm/rpmbuild tools? Virtually, every Embedded
> Linux vendor has modified rpm to make it behave properly for
> cross-building etc. It would be a good idea if we can get this done
> right in upstream rpm.

No, nothing was needed to change in the build host rpmbuild, it works
fine with rpmbuild that comes from FC6 and FC7 as it is including using
rpmbuild --target to set the arch.  The spec files are just normal spec
files.

The only trick was to define a new dir under %_topdir called
devel-filesystem-%{_target_cpu}.  When you package a lib for a given
%{_target_cpu} (set by --target on rpmbuild), you use a script to rpm -i
--root=%_topdir/devel-filesystem-%{_target_cpu} the target-compiled
package and any -devel package into the *build host*.  Then when you
come to cross build an app that wants the target lib, you ensure in the
%build that it gets configured and built with
CFLAGS="-I%_topdir/devel-filesystem-%{_target_cpu}/usr/include" or
whatever and likewise for LDFLAGS.  Plus you need something like
CROSS=/opt/%{_target_cpu}/bin/%{_target_cpu)-linux- or to set
./configure --host=%{_target_cpu} or otherwise meddle with reality so
that the correct CC is used.

The earlier packages have dirty hacks to get them to crosscompile in
some cases, as I went on I found better ways to come at it (like
recooking the configure with later autotools and just patching the
things that broke from autotools version changes).

On the targets I use it on I can't afford the rpm client app and libs
(8MByte NOR flash for everything), so I made a mini rpm client on top of
the basic rpm/cpio unpack support that is in busybox already (patch is
in the SRPM for Octotux busybox).  Instead of a database it snips the
RPM header off installed packages and stashes them in /var/lib/rpm, and
walks them to determine the requires and provides situation (re-using
the existing header parsing code needed anyway for install/query).  It's
as scalable as it needs to be given that you only use it when the
platform is too small to handle the real RPM... and throughout the
actual packages themselves are genuine full normal RPMs.

>> Perl and Python are the holdouts I did not bother to spend more than a
>> day on, since they currently try to use their own target-compiled
>> binaries as part of their build process.
> 
> They can (and have been) tamed too :-)

Yep I didn't doubt they could be tamed ;-)  I was able to redefine my
need for them by selecting a different app that initially wanted them
though -- for perl it was binning postgrey for the C-based gps IIRC.

-Andy