On Wed, Jan 10, 2007 at 11:06:27PM +0200, Guillem Jover wrote:
> > 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.
OK.
> > 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).
OK.
> > 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.
One wonders, should it be stripping the -gnu from $target_os at all?
It it maps arm-linux-gnu to arm-linux, what should arm-linux-gnueabi
be mapped to? arm-linux as well? or 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__).
>
> 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. ;)
OK.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
