On Thu, Mar 17, 2005 at 08:44:44PM -0600, Manoj Srivastava wrote: > On Thu, 17 Mar 2005 21:16:51 +0100, Robert Millan <[EMAIL PROTECTED]> said: > > > On Thu, Mar 17, 2005 at 10:21:58AM -0600, Manoj Srivastava wrote: > >> Hi, > >> > >> Could you rework this patch with latest version of kernel-package, > >> and make it as little intrusive as possible? The current patch no > >> longer applies cleanly, and makes too many changes that I could not > >> see a reason for. > > > I always try to make my patches as little intrusive as possible, but > > this one needed many changes and it's not easy to reduce them. > > > Could you point out which of the changes you don't like? Then I > > could send you a partial patch with only the stuff you like, so that > > I don't have to work as much on a moving target. After that, I'll > > be happy to discuss the rest of the hunks with you. > > ====================================================================== > - architecture:=$(DEB_HOST_ARCH) > > + architecture:=$(DEB_HOST_GNU_CPU) > > + ifeq ($(architecture), x86_64) > > + architecture:=amd64 > > + endif > ====================================================================== > > Umm. Are you sure it shall not break any other arch there? It > shall break amd64, for instance, and perhaps the hurd ....
DEB_HOST_ARCH contains mixed information about cpu and system (when system is not specified, it implies linux). Your use of this variable requires that it matches with the way Linux calls the cpus it supports. So the information we need is not (at least, not directly) the system we're running on. That's why DEB_HOST_GNU_CPU is the correct variable to use, and not DEB_HOST_ARCH which would add prefixes like "kfreebsd-" or "hurd-" which GnuMach or the kernel of FreeBSD don't recognise as part of their CPU naming conventions. Note, however, that the discrepancy between DEB_HOST_GNU_CPU and Linux CPU naming convention happens to be exactly the same discrepancy as the one between DEB_HOST_GNU_CPU and kFreeBSD CPU naming convention (i.e. only amd64 differs). If make-kpkg ever supported GnuMach *and* GnuMach supported amd64, we can't predict if this discrepancy would also happen. It solely depends on wether GnuMach refers to that CPU as x86_64 or amd64, and is not an issue we can address now. In any case, using DEB_HOST_ARCH is totaly broken for non-Linux since then the discrepancy would be between "kfreebsd-i386" and "i386", between "kfreebsd-alpha" and "alpha", etc, etc. > ifndef CROSS_COMPILE > > ifeq ($(strip $(MAKING_VIRTUAL_IMAGE)),) > > ifneq ($(strip $(architecture)),$(strip $(DEB_BUILD_ARCH))) > > - KERNEL_CROSS:=$(architecture)-$(strip $(DEB_HOST_GNU_SYSTEM))- > > + KERNEL_CROSS:=$(DEB_HOST_GNU_TYPE) > > endif > > endif > ====================================================================== > > This certainly looks wrong. IIRC i intended the second option to be a simplified form of the first, but my make skills are not very good so I probably missed something. Could you ellaborate? -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `' http://www.debian.org/ports/kfreebsd-gnu `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
