We're devolving a bit into implementation, but if you use the "sysroot" facility of binutils and gcc cross compilers many of the issues go away, and you can use much of Fedora packaging directly.

The biggest issue is to make sure that CC, LD, AS, etc are all set correctly prior to calling configure and attempting to cross compile.

Give me a bit of time, and I'll show some examples.. I have to get up to speed w/ rpm 4_5 development first.


-----Original Message-----
From: rpm-devel-owner@rpm5.org on behalf of Andy Green
Sent: Mon 6/4/2007 4:28 PM
To: rpm-devel@rpm5.org
Subject: Re: reference implementation
 
Andy Green wrote:
> Jeff Johnson wrote:
> 
>>>> Are EABI and/or NPTL needed for *building*? Sure they are needed
>>>> for installing on the target.
>>> NPTL is probably a no.  But EABI is a yes.  You can't mix OABI and
>>> EABI binaries.  All of the embedded ARM development has moved to EABI
>>> binaries.  (As an aside, the purpose of EABI is to allow for a fixed
>>> calling convention so that regardless of the optimizations embedded in
>>> the binaries, they will still work with each other..  no problems w/
>>> hard vs soft float vs "vfp" float.. etc.  OABI had to "change"
>>> everytime someone changed the floating point or register sets
>>> available to an app!)
>>>
>> Apologies for my lack of knowledge on ARM.
>>
>> So why not sparate OABI and EABI qemu sysimages?
>>
>> (the lights come on, EABI doesn't work with qemu)
>>
>> OK, so EABI has to be cross-compiled unitil qemu can emulate.
>>
>> OABI -> sysimage still seems viable.
> 
> My lights must still be off, I don't see why you need qemu to build the
> cross packages at all.  It's like I might want to make a PowerPC binary
> rpm for some package, but I don't have a PowerPC.  That's okay if I am
> using this proposed Cross-Fedoraish thing, I can tell my i386 box to
> cross build my Ultrafoo package as a PowerPC binary RPM.  Or if all I
> have is a PowerPC, I can make i386 binary rpms of my package.
> 
> Where does EABI come into it?  That you need a crosscompiled EABI uclibc
> lib on the target to link to?  Well that's easily done without needing
> any emulation on the build host.

Just to explain this a bit further, what I did with Octotux was to add a
dir devel-filesystem-%{_target_cpu} under %_topdir, so for example there
was %_topdir/devel-filesystem-arm.

After I built a crosscompiled package that I wanted to let other
packages be built against, say I built libdb4 for ARM and now I wanted
to build postfix for arm that wants libdb4, I used a script to "install"
my arm libdb4 and libdb4-devel rpms into the *build* host using
--root=%_topdir/devel-filesystem-arm.  Then when I cross-built postfix
for ARM, I took care to tell postfix's configure to have CFLAGS with
-I%_topdir/devel-filesystem-%{_target_cpu}, so it picks up the right libs.

Basically .../rpm/devel-filesystem-arm is a little island of ARM
libraries and include files on the build host that other ARM builds can
use, and they have all come out of the actual rpms that will later be
installed on the real target.

I already build for arm and avr32 on the same build host -- from the
same spec file -- using this system and it works fine, with no emulation
needed anywhere.

The existing Fedora spec files %build stuff won't work like that as it
is, they only support the build host arch being the target arch.

-Andy
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org