Re: Bug#344833: attached an ugly and hacky patch which allows me to build 2.6.15 on powerpc.
On Tue, Dec 27, 2005 at 03:36:46AM -0600, Manoj Srivastava wrote:
> On Tue, 27 Dec 2005 09:44:20 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
>
> > On Mon, Dec 26, 2005 at 10:23:20PM -0600, Manoj Srivastava wrote:
> >> Hi,
> >>
> >> Umm. I'll accept part of this patch -- the part where you set
> >> KERNEL_ARCH based on KPKG_SUBARCH. I'm not going to change the
> >> common/* stuff just for ppc. If it appears that needs changing,
> >> then there is a bug elsewhere.
>
> > Well, Then you didn't fix anything at all, really. You make a wrong
> > assumption on the kernel ARCH vs the debian architecture,
>
> I designed this stuff. I know what the --arch argument to k-p
> means. I, however, have no idea what you mean by "debian
> architecture", or what the significance of that might be, but it is
> not a kernel-package thing, so I am not sure what I am supposed to do
> with that.
What is returned by dpkg-architecture obviously :)
> And the kernel architiceture is what is passed to the kernel
> Makefile as ARCH=ffo, and kernel-package stores it under KERNEL_ARCH
Indeed, and it happens that all manner of tools break when the debian
architecture (the one returned by dpkg-architecture) is different from the
kernel architecture (the one you set ARCH=foo when building the kernel).
> > and this breaks in cases like powerpc where there is not a 1-1
> > mapping between both, i guess amd64 also suffer from this problem,
> > but i am not sure how you solved this.
>
> No, it does not. ANd neither does amd64 break.
That is not what fs was saying earlier, as amd64 has the same problem of the
kernel arch (x86_64) being different from the debian arch (amd64).
> > The other day you complained i just filled a bug report without
> > investigating, and now i investigated, and you just refuse to fix
> > the brokeness, claiming there is a bug elsewhere or something.
>
> If there was brokenness to fix in the way you imagine, I
> would.
There is at least a problem in the documentation, if nothing else, but it is
not like your comments where helpful in making things clearer, which sucks.
But we solved the issue on irc, but i think this is a problem in the
usefulness of using debian bug report for communicating about a bug or
something.
> > So, to make things clear, the official powerpc debian/dpkg arch is
> > powerpc,
>
> Well, that's fine and dandy. I am not sure I know what
> "debian/dpkg arch" means, though, and What does this have to do with
> kernel-package, anyway?
i think it is obvious enough what is meant by that :)
> > the unnofficial andreas-jochens-pure64 debian/dpkg arch is ppc64,
> > and the future multi-arch 64bit powerpc debian/dpkg arch will be
> > powerpc64, once we have multi-arch support.
>
> Again, unless this is what we pass to the kernel as ARCH=foo
> (KERNEL_ARCH, in other words), I am not sure of the significance.
Nope, and this is the main problem here, that the dpkg-* architecture is not
the same string as the kernel expect.
> > On the kernel side, upto now, we had two kernel archs (ARCH=ppc for
> > 32bit and ARCH=ppc64 for 64bit), and we are slowly merging this into
> > a single ARCH=powerpc. ARCH=ppc64 has dissapeared and is replaced by
> > ARCH=powerpc since
> > 2.6.15 (including the -rc ones), and the 32bit powerpc arch can
> > build with
> > both ARCH=ppc and ARCH=powerpc as of 2.6.15, it is expected that
> > ARCH=ppc will go away in 2.6.16 or soon thereafter.
>
> OK, good, I understand this. I think we are more or less on
> the right track here.
Hehe.
> > Since kernel-package aims to be able to build kernels for newer and
> > older kernels, we need to support all three cases. In order to do
> > this, we need to be able to set the ARCH field accordying to version
>
> No, ARCH is the wrong thing to set here. We should be using
> --subarch.
Yeah, altough --kernel-arch as an override to whatever --subarch sets as
default would be a good feature, i believe, and rather cheap to do even.
> > and 32/64 bitness. I used to hardcode the ARCH from the KPKG_SUBARCH
> > (powerpc->ARCH=ppc,
> powerpc64-> ARCH=ppc64), but this is no more future proof, and i
> powerpc64-> believe was
> > kind a suboptimal back then. The right way is to be able to tell
> > make-kpkg the ARCH to use, which i believe is what the --arch arg is
> > supposed to be for, but you are making a confusion between the
> > debian/dpkg arch and the kernel arch, which is the cause of this
> > problem.
>
>
> No. --arch is not meant to be used like that.
Indeed, please clarify the documentation on this, but this leaves a sore
point, namely i believe we need to provide some documentation to our users for
what exactly the --subarches do, and i didn't really see this documented
properly anyway except the per-arch snipplets.
> > So, it would be nice if you could define clearly what the --arch is
> > for, to set the debian/dpkg arch or the kernel arch, and if we
> > really need to be able to set the debian/dpkg arch in this way, then
> > you need also to provide an option for setting the kernel arch.
>
>
> --arch is DEB_HOST_ARCH_CPU (or DEB_HOST_GNU_CPU, if that
> does not exist). If you tell kerel-package some value of arch that is
> different from DEB_HOST_ARCH_CPU, kernel-package knows you are cross
> compiling.
Indeed, but the kernel arch is different.
> > Current code, apart from the purely powerpc case, and my unsureness
> > of chosing the ARCH=ppc or ARCH=powerpc for 2.6.15, make two broken
> > assumptions about this :
>
> > 1) the --arch seems clearly to be used only for cross compilation,
> > and altough you have a funny and unexplained powerpc64 special
> > casing, it doesn't really solve the problem in his generality.
>
> The special casing is gone, and seems to have been a
> historical artifact.
Cool.
> > 2) kernel-package goes under the assumption that the kernel ARCH
> > is the same as the debian architecture, which is obviously
> > wrong.
>
> You are wrong about that. kernel-package _defaults_ to setting
> kernel ARCH to be the same as DEB_HOST_ARCH_CPU, but does not
> _assume_ they are the same. Big difference.
but you have no way of setting it to something different, except by editing
the arch-specific snipplet.
> > So, all in all, i think the bug is in kernel-package, and we are
> > dependent on you fixing it properly to be able to again build
> > kernels on powerpc, which probably includes both 2.6.15 and 2.6.14
> > and all older kernels in the current state of things.
>
> The bug, really, is in the invocation. And perhaps powerpc.mk,
> ppc.mk, and ppc64.mk may need changes to ensure everything works
> correctly, and I'll install new versions of those files as soon as
> you send them to me.
Ok, i think we should kill ppc.mk and ppc64.mk and work things out in
powerpc.mk. I will provide you a patch this evening.
Friendly,
Sven Luther
Reply to: