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:
dpkg_1.13.24_armel.deb
dpkg-dev_1.13.24_all.deb
dselect_1.13.24_armel.deb
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: