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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
