[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: arm eabi port, patches

On Wed, Jan 10, 2007 at 04:53:01PM +0000, Wookey wrote:

> > More and more VFP-supporting CPUs are coming out lately, and it would
> > be nice to be able to use VFP on them in a sane way.  The existing
> > Debian EABI efforts have been taking a while, so November 24 last year
> > I started working on a from-scratch EABI port, sponsored by Applied
> > Data Systems (http://www.applieddata.net/)  Six and a half weeks later,
> > there's about 6000 debs built, and so far it all seems to work pretty
> > well.
> Well done that man. You have indeed overtaken us. (what are you
> building on/with?)

Two thecus n2100 kindly donated and hosted by Applied Data Systems,
one thecus n2100 kindly donated by Thecus, and one Intel IQ81342EX
dual-core 800MHz iop342-with-512K-L2-cache-per-cpu-core-and-ddr2-ram
evaluation board kindly donated by Intel.

> > I can't share the debs yet (internal and customer use only for now),
> > but I would like to get consensus on armel patches before I start
> > submitting them.
> > 
> > The first candidate is dpkg.  Guillem Jover's patch available here:
> > 
> > 	http://lists.debian.org/debian-embedded/2006/05/msg00032.html
> I was having a go at this last week. 
> Does that build for you natively?

Yup, as does everything else built so far.  I've not used dpkg-cross
for anything.

I bootstrapped off an OpenEmbedded Angstrom (EABI) rootfs mixed with
Fedora Core 6 EABI packages.  (I've also done a Fedora Core 6 ARM EABI
port.)  The OpenEmbedded people have done an excellent job at getting
an ARM EABI distribution up and running for me to bootstrap from, it
definitely saved me a lot of time.

> I got mysterious m4 errors last week and haven't had a chance to work
> out why yet. I'd like to compare notes. I also noticed that a lot of
> stuff changes again in dpkg 1.13.24 (which is current in etch) and it
> wasn't immediately obvioushow to forward-port that patch (so I didn't,
> and wrestled feebly with the above).

We're using 1.13.24 as well:


Dunno, it builds fine for me.  If you send me your build log I can
have a look.

> > changes DEB_HOST_GNU_{SYSTEM,TYPE} to have -gnueabi at the end.  I've
> > found that this doesn't work too well.  For example, util-linux does
> > stuff like this all over debian/rules:
> > 
> > 	ifeq ($(DEB_HOST_GNU_SYSTEM),linux-gnu)
> > 	MOUNTBINFILES  = mount/mount mount/umount
> > 	MOUNTSBINFILES = mount/swapon mount/losetup
> > 	endif
> > 
> > And ruby1.8 does:
> > 
> > 	arch_dir  = $(subst linux-gnu,linux,$(target_os))
> > 
> > (which turns arch_dir into arm-linuxeabi instead of arm-linux-eabi.)
> > 
> > I asked Joey Hess, and he felt that there are probably more packages
> > that depend on linux-gnu than on having gnueabi, which makes sense.
> > The only packages that really need to know about gnueabi are binutils,
> > gcc and glibc, the rest should just be checking defined(__ARM_EABI__).
> > 
> > Opinions?
> I had wondered the same thing myself, but thought I should worry about
> that after making it build.
> I agree that linux-gnu seems more sensible, but then what is necessary
> to get glibc and gcc to configure themselves right?

Add 'eabi' to the end of the target triple(s) when running configure
-- that's about it.

Reply to: