Before the arch merge, I frequently would test 32bit compiles
by doing make ARCH=i386 {bzImage/modules/file.o}
Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
how does one do this?
Dave
--
http://www.codemonkey.org.uk
On Mon, Oct 29, 2007 at 07:32:31PM -0400, Dave Jones wrote:
> Before the arch merge, I frequently would test 32bit compiles
> by doing make ARCH=i386 {bzImage/modules/file.o}
>
> Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
> how does one do this?
Same. Top-level makefile kludges around that:
SRCARCH := $(ARCH)
# for i386 and x86_64 we use SRCARCH equal to x86
SRCARCH := $(if $(filter x86_64 i386,$(SRCARCH)),x86,$(SRCARCH))
and then plays with both ARCH and SRCARCH. Note
# If a arch/$(SRCARCH)/Kconfig.$(ARCH) file exist use it
ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/Kconfig.$(ARCH)),)
Kconfig := arch/$(SRCARCH)/Kconfig.$(ARCH)
else
Kconfig := arch/$(SRCARCH)/Kconfig
endif
in scripts/kconfig/Makefile, BTW - now we use arch/x86/Kconfig.i386 and
arch/x86/Kconfig.x86_64 as starting points for ARCH=i386 and ARCH=x86_64
resp.
Dave Jones wrote:
> Before the arch merge, I frequently would test 32bit compiles
> by doing make ARCH=i386 {bzImage/modules/file.o}
>
> Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
> how does one do this?
>
make ARCH=i386 {bzImage/modules/file.o}
Amazing, isn't it?
-hpa
On Mon, Oct 29, 2007 at 05:07:08PM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> > Before the arch merge, I frequently would test 32bit compiles
> > by doing make ARCH=i386 {bzImage/modules/file.o}
> >
> > Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
> > how does one do this?
> >
>
> make ARCH=i386 {bzImage/modules/file.o}
>
> Amazing, isn't it?
It's like the future. I'm not sure why that didn't work for me.
Must be something in my dirty tree.
Dave
--
http://www.codemonkey.org.uk
On Mon, Oct 29, 2007 at 05:07:08PM -0700, H. Peter Anvin wrote:
> Dave Jones wrote:
> >Before the arch merge, I frequently would test 32bit compiles
> >by doing make ARCH=i386 {bzImage/modules/file.o}
> >
> >Since commit 47572387d58a9584c60ebbbdee56fc92c627f16f
> >how does one do this?
> >
>
> make ARCH=i386 {bzImage/modules/file.o}
Which seems rather unnatural to me. All other merge architectures have
ARCH=<archdir> where archdir is the name under arch, e.g. mips, powerpc,
s390. They then have a CONFIG_FOO_64 and set the utsname and -m32/-m64
respectively. It would be nice if x86 could behave like all other
architectures in this respect. Especially as the behaviour of the other
architectures is a lot more intuitive.
>
> Amazing, isn't it?
>
> -hpa
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
Christoph Hellwig wrote:
> Which seems rather unnatural to me. All other merge architectures have
> ARCH=<archdir> where archdir is the name under arch, e.g. mips, powerpc,
> s390. They then have a CONFIG_FOO_64 and set the utsname and -m32/-m64
> respectively. It would be nice if x86 could behave like all other
> architectures in this respect. Especially as the behaviour of the other
> architectures is a lot more intuitive.
>
Yes, that would be nice. I keep forgetting the ARCH= in my crossbuild
trees, and end up with strange mismashes.
J
Jeremy Fitzhardinge wrote:
> Christoph Hellwig wrote:
>> Which seems rather unnatural to me. All other merge architectures have
>> ARCH=<archdir> where archdir is the name under arch, e.g. mips, powerpc,
>> s390. They then have a CONFIG_FOO_64 and set the utsname and -m32/-m64
>> respectively. It would be nice if x86 could behave like all other
>> architectures in this respect. Especially as the behaviour of the other
>> architectures is a lot more intuitive.
>>
>
> Yes, that would be nice. I keep forgetting the ARCH= in my crossbuild
> trees, and end up with strange mismashes.
>
That, however, is a bigger problem that also affects, for example,
compiling for MIPS on an x86 host. I believe Sam is working on a
solution for that.
(That doesn't mean that is not the right thing to do.)
-hpa
On Tue, Oct 30, 2007 at 06:00:01PM -0700, Jeremy Fitzhardinge wrote:
> Christoph Hellwig wrote:
> > Which seems rather unnatural to me. All other merge architectures have
> > ARCH=<archdir> where archdir is the name under arch, e.g. mips, powerpc,
> > s390. They then have a CONFIG_FOO_64 and set the utsname and -m32/-m64
> > respectively. It would be nice if x86 could behave like all other
> > architectures in this respect. Especially as the behaviour of the other
> > architectures is a lot more intuitive.
> >
>
> Yes, that would be nice. I keep forgetting the ARCH= in my crossbuild
> trees, and end up with strange mismashes.
That's a problem with all architectures currently. But I think Sam has
a patch that at least stores ARCH when using objdir != srcdir builds.
On Wed, Oct 31, 2007 at 08:57:39AM +0000, Christoph Hellwig wrote:
> On Tue, Oct 30, 2007 at 06:00:01PM -0700, Jeremy Fitzhardinge wrote:
> > Christoph Hellwig wrote:
> > > Which seems rather unnatural to me. All other merge architectures have
> > > ARCH=<archdir> where archdir is the name under arch, e.g. mips, powerpc,
> > > s390. They then have a CONFIG_FOO_64 and set the utsname and -m32/-m64
> > > respectively. It would be nice if x86 could behave like all other
> > > architectures in this respect. Especially as the behaviour of the other
> > > architectures is a lot more intuitive.
> > >
> >
> > Yes, that would be nice. I keep forgetting the ARCH= in my crossbuild
> > trees, and end up with strange mismashes.
>
> That's a problem with all architectures currently. But I think Sam has
> a patch that at least stores ARCH when using objdir != srcdir builds.
kbuild check's the asm symlink and error out if it is wrong.
So forgetting ARCH should be captured. But the check does not
store ARCH which is what I hope to have fixed for next merge window.
So for now if you forget ARCH you should be warned.
And in the future kbuild will remember what ARCH (and CROSS_COMPILE)
you used when configuring the kernel.
For x86 the current check does not help use because the asm symlink
is the same for i386 and x86_64 - so for now we are out of luck.
Sam