Re: arm eabi port, patches

[Guillem Jover <guillem@debian.org>]

Hi,

On Wed, 2007-01-10 at 17:11:23 +0100, Lennert Buytenhek 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.

Nice!

> 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

Now that I've opened dpkg's trunk for 1.14 (targetted for lenny), I'll
be appliying a cleaner version of the patch, those versions will be
going to experimental for now.

> changes DEB_HOST_GNU_{SYSTEM,TYPE} to have -gnueabi at the end.  I've
> found that this doesn't work too well.

GNU_{SYSTEM,TYPE} map to the gnu triplet stuff, so whatever is in
there should be in those variables, and those variables should be used
mostly only for configure scripts, or similar stuff.

> 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

This is would be broken, it should be using ($(DEB_HOST_ARCH_OS),linux).

> And ruby1.8 does:
> 
> 	arch_dir  = $(subst linux-gnu,linux,$(target_os))
>
> (which turns arch_dir into arm-linuxeabi instead of arm-linux-eabi.)

The same for this one.

> 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__).

I'd say it's good that those break, thet expose problems in the abuse
and assumptions of those packages when using the wrong variables, and
fixing this may help with portability in the future. ;)

regards,
guillem