Make m68k cross compile like every other architecture.
PATCH 1/1 Make m68k cross compile like every other architecture.
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
---
When you cross compile, you have to set the prefix CROSS_COMPILE to your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.
The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
arch/m68k/Makefile | 7 ------- 1 file changed, 7 deletions(-)
arch/m68k/Makefile +0 -7
@@ -13,17 +13,10 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compiling -COMPILE_ARCH = $(shell uname -m) - # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -ifneq ($(COMPILE_ARCH),$(ARCH)) - # prefix for cross-compiling binaries - CROSS_COMPILE = m68k-linux-gnu- -endif ifdef CONFIG_SUN3 LDFLAGS_vmlinux = -N
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Geert Uytterhoeven
maintainerQuoted 5 lines · Rob Landley
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>
Quoted 8 lines
---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
Quoted 14 lines
arch/m68k/Makefile | 7 ------- 1 file changed, 7 deletions(-)diff -r
79f0ea1e0e70arch/m68k/Makefilearch/m68k/Makefile +0
-3@@ -13,17 +13,10 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compiling -COMPILE_ARCH = $(shell uname -m) - # override top level makefile
arch/m68k/Makefile line 22
Quoted 10 lines
arch/m68k/Makefile +0
-4AS += -m68020 LDFLAGS := -m m68kelf LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -ifneq ($(COMPILE_ARCH),$(ARCH)) - # prefix for cross-compiling binaries - CROSS_COMPILE = m68k-linux-gnu- -endif ifdef CONFIG_SUN3 LDFLAGS_vmlinux = -N
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 12 lines · Geert Uytterhoeven
Quoted 11 lines · Rob Landley
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.
Quoted 8 lines
Quoted 3 lines
The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
I noticed this because you have to specify ARCH for "make headers_install" but don't have to specify a CROSS_COMPILE prefix for that because it doesn't build anything. Yet the first line it spits out is a complaint that it can't find m68k-linux-gnu-gcc.
I do note that the error message doesn't stop the build, and seems to be ignored...
Quoted 1 line
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
*shrug* This is the eleventh target I've tried to build, and the first one that has this behavior. It seemed unnecessary at best.
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 15 lines · Geert Uytterhoeven
Quoted 5 lines · Rob Landley
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>Quoted 8 lines
---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
Quoted 6 lines
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
For "make headers_install" this is not good.
But I see there is confliting usages here.
1) current functionality makes it easy to build a cross compiled m68k
2) suggested functionality makes it easy to do make headers_install
Btw. if you did:CROSS_COMPILE ?= m68k-linux-
then I could do:
export CROSS_COMPILE=my-m68k-linux-
make
and still get the expected result.
Sam
Quoted 41 lines
Quoted 15 lines
arch/m68k/Makefile | 7 ------- 1 file changed, 7 deletions(-)diff -r
79f0ea1e0e70arch/m68k/Makefilearch/m68k/Makefile +0
-3@@ -13,17 +13,10 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compiling -COMPILE_ARCH = $(shell uname -m) - # override top level makefilearch/m68k/Makefile line 22
Quoted 10 lines
arch/m68k/Makefile +0
-4AS += -m68020 LDFLAGS := -m m68kelf LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -ifneq ($(COMPILE_ARCH),$(ARCH)) - # prefix for cross-compiling binaries - CROSS_COMPILE = m68k-linux-gnu- -endif ifdef CONFIG_SUN3 LDFLAGS_vmlinux = -NGr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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/
Geert Uytterhoeven
maintainerQuoted 27 lines · Sam Ravnborg
Quoted 15 lines · Geert Uytterhoeven
Quoted 5 lines · Rob Landley
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>Quoted 8 lines
---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
Quoted 6 lines
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
For "make
headers_install" this is not good.
But I see there is confliting usages here.
1) current functionality makes it easy to build a cross compiled m68k
Quoted 8 lines
Btw. if you did:
CROSS_COMPILE?= m68k-linux-then I could do:
export CROSS_COMPILE=my-m68k-linux-
makeand still get the expected result.
That won't work, cfr. http://lkml.org/lkml/2007/5/6/58.
Quoted 1 line
2) suggested functionality makes it easy to do make
headers_install
This is something completely different (cfr. the other thread handling it). If `make headers_install' doesn't need the cross compiler, it should not try to execute it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 34 lines · Geert Uytterhoeven
Quoted 33 lines · Sam Ravnborg
Quoted 18 lines · Geert Uytterhoeven
Quoted 13 lines · Rob Landley
From: Rob Landley <[email protected]>
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.Quoted 3 lines
The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
Quoted 6 lines
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
For "make
headers_install" this is not good.
But I see there is confliting usages here.
1) current functionality makes it easy to build a cross compiled m68kBtw. if you did:
CROSS_COMPILE?= m68k-linux-
Quoted 7 lines
Quoted 5 lines
then I could do:
export CROSS_COMPILE=my-m68k-linux-
makeand still get the expected result.
That won't work, cfr. http://lkml.org/lkml/2007/5/6/58.
Reading the patch in that link, recent cross compilers from _where_? Buildroot? Cross-tools? Gentoo embedded? Cross Linux From Scratch? My Firmware Linux project?
You assume they all use the same name, yet your patch changes them from one default name to another default name, presumably due to a gcc version change becoming increasingly political about the GNU/Linux/Dammit thing...
None of the other targets I've tried attempt to _supply_ a default. Just like the Linux kernel errors out early in the build if you distclean and then try to run "make" without having run config first. It doesn't run "defconfig" for you and continue on in that case. But m68k, uniquely, assumes it knows what you want to do when you didn't tell it. Other targets do not do this.
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 28 lines · Rob Landley
Quoted 11 lines · Geert Uytterhoeven
Quoted 10 lines · Sam Ravnborg
Quoted 1 line · Geert Uytterhoeven
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
For "make
headers_install" this is not good.
But I see there is confliting usages here.
1) current functionality makes it easy to build a cross compiled m68kBtw. if you did:
CROSS_COMPILE?= m68k-linux-Quoted 7 lines
Quoted 5 lines
then I could do:
export CROSS_COMPILE=my-m68k-linux-
makeand still get the expected result.
That won't work, cfr. http://lkml.org/lkml/2007/5/6/58.
Reading the patch in that link, recent cross compilers from _where_? Buildroot? Cross-tools? Gentoo embedded? Cross Linux From Scratch? My Firmware Linux project?
You assume they all use the same name, yet your patch changes them from one default name to another default name, presumably due to a gcc version change becoming increasingly political about the GNU/Linux/Dammit thing...
Quoted 6 lines
None of the other targets I've tried attempt to _supply_ a default. Just like the Linux kernel errors out early in the build if you distclean and then try to run "make" without having run config first. It doesn't run "defconfig" for you and continue on in that case. But m68k, uniquely, assumes it knows what you want to do when you didn't tell it. Other targets do not do this.
Many platforms used to do this. For most of them it didn't end up being useful given all of the target variant, so they just got removed. If that's not the case for m68k and it's still useful for people there, then there's no reason to remove it. If you want to overload it you are free to, but Geert is right that headers_install shouldn't be calling the cross compiler if it has no dependency on it. Fixing bugs is preferable to fixing symptoms.
Geert Uytterhoeven
maintainerQuoted 41 lines · Rob Landley
Quoted 32 lines · Geert Uytterhoeven
Quoted 31 lines · Sam Ravnborg
Quoted 16 lines · Geert Uytterhoeven
Quoted 11 lines · Rob Landley
Rip out hardwired cross compiler name assumption that only m68k makes.
Signed-off-by Rob Landley <[email protected]>---
When you cross compile, you have to set the prefixCROSS_COMPILEto your cross compiler prefix. You need to do this for all targets (arm, mips, ppc, x86-64 on x86, etc). This is not specific to m68k, and this value is supplied _to_ the build, not supplied _by_ the build.Quoted 3 lines
The build shouldn't unconditionally overwrite the existing value of this variable with one it makes up. It has no idea what I called my cross compiler.
Quoted 6 lines
The build does not unconditionally overwrite the existing value of this variable. You can specify the name of your cross compiler like this:
make CROSS_COMPILE=m68k-linux-
BTW, m68k-linux-gnu- is the default name for a m68k cross compiler.
For "make
headers_install" this is not good.
But I see there is confliting usages here.
1) current functionality makes it easy to build a cross compiled m68kBtw. if you did:
CROSS_COMPILE?= m68k-linux-Quoted 7 lines
Quoted 5 lines
then I could do:
export CROSS_COMPILE=my-m68k-linux-
makeand still get the expected result.
That won't work, cfr. http://lkml.org/lkml/2007/5/6/58.
Quoted 7 lines
Reading the patch in that link, recent cross compilers from _where_? Buildroot? Cross-tools? Gentoo embedded? Cross Linux From Scratch? My Firmware Linux project?
You assume they all use the same name, yet your patch changes them from one default name to another default name, presumably due to a gcc version change becoming increasingly political about the GNU/Linux/Dammit thing...
Compilers build from the only remaining distribution that supports (sort of) m68k: Debian.
Quoted 1 line
None of the other targets I've tried attempt to _supply_ a default. Just like
Obviously you haven't tried them all...
Quoted 4 lines
the Linux kernel errors out early in the build if you distclean and then try to run "make" without having run config first. It doesn't run "defconfig" for you and continue on in that case. But m68k, uniquely, assumes it knows what you want to do when you didn't tell it. Other targets do not do this.
If you cross compile for m68k and don't specify a toolchain, you get a default one: the one the m68k developers use.
On some other architectures, you always have to specify the toolchain. What's wrong with providing a default?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 11 lines · Geert Uytterhoeven
Quoted 8 lines
Reading the patch in that link, recent cross compilers from _where_? Buildroot? Cross-tools? Gentoo embedded? Cross Linux From Scratch? My Firmware Linux project?
You assume they all use the same name, yet your patch changes them from one default name to another default name, presumably due to a gcc version change becoming increasingly political about the GNU/Linux/Dammit thing...
Compilers build from the only remaining distribution that supports (sort of) m68k: Debian.
Maybe. I use an old Cross LFS build, as well as Debian (does Debian officially support m68k?), and there also exists an unofficial Gentoo port.
Quoted 5 lines
If you cross compile for m68k and don't specify a toolchain, you get a default one: the one the m68k developers use.
On some other architectures, you always have to specify the toolchain. What's wrong with providing a default?
Nothing, except that uniformity across platforms follows the principal of least suprise. That generally makes life easier downstream.
I personally have created and used m68k cross toolchains as "m68k-linux", "m68k-linux-gnu" and "m68k-unknown-linux-gnu". AFAIK it's quite arbitrary.
This wasn't an issue before we came to depend on cross compilers. Since we tend to need them more as compilation becomes more expensive, IMHO we should follow the practice of the embedded architectures.
-f
Quoted 4 lines
Gr{oetje,eeting}s,
Geert
Quoted 10 lines · Finn Thain
Quoted 9 lines · Geert Uytterhoeven
Quoted 8 lines
Reading the patch in that link, recent cross compilers from _where_? Buildroot? Cross-tools? Gentoo embedded? Cross Linux From Scratch? My Firmware Linux project?
You assume they all use the same name, yet your patch changes them from one default name to another default name, presumably due to a gcc version change becoming increasingly political about the GNU/Linux/Dammit thing...
Quoted 6 lines
Quoted 2 lines
Compilers build from the only remaining distribution that supports (sort of) m68k: Debian.
Maybe. I use an old Cross LFS build, as well as Debian (does Debian officially support m68k?), and there also exists an unofficial Gentoo port.
I noticed the cruft in this target because I'm attempting to support it in Firmware Linux (http://landley.net/code/firmware), on the theory that a patch was posted to the qemu mailing list to add m68k support to qemu, so it's probably only a matter of time until it gets merged and an m68k system board added to the emulator:
http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00015.html
If the _goal_ is that Debian be the only distribution to support m68k, then obviously the name it uses can be hardwired into the code because that's all that can ever matter, by definition.
Quoted 11 lines
Quoted 5 lines
If you cross compile for m68k and don't specify a toolchain, you get a default one: the one the m68k developers use.
On some other architectures, you always have to specify the toolchain. What's wrong with providing a default?
Nothing, except that uniformity across platforms follows the principal of least suprise. That generally makes life easier downstream.
I personally have created and used m68k cross toolchains as "m68k-linux", "m68k-linux-gnu" and "m68k-unknown-linux-gnu". AFAIK it's quite arbitrary.
My toolchains override the default prefix to just the target, resulting in "m68k-gcc". (It's shorter, and when you're creating a dozen toolchains having them all say -linux- in the middle of every command name gets a bit silly...)
When it started complaining about "m68k-linux-gnu-gcc" (which is _not_ what my cross compiler is called) I spent half an hour tracking down where it was getting that name from and what exactly was going on. (Was my build script supplying the wrong name? Did something set an environment variable it shouldn't have? Did the gcc build suddenly reveal another strange buried corner case that made it revert to a default against explicit instructions _again_?)
When I found the surprising behavior that cost me time and effort to diagnose, I submitted a patch so it wouldn't confuse future developers the first time _they_ try to build m68k. (Yes, I think there might be such. Call me crazy.) I've seen "didn't specify any cross compiler" failures before, on arm and x86-64 and mips and sparc and so on. I've seen it in the linux kernel, in busybox, in uClibc, and in various gnu packages
with ./configureitis. This is the first time I've seen a package confidently decide for itself to use a compiler name that isn't in the $PATH, and especially the first time I've seen Linux do it. It cost me time to disagnose because it looks like it's getting a CROSS_COMPILE setting from its environment somehow, and the logical thing to do is look at that environment (and the build scripts driving it, and the temp files) to see where such a thing might be leaking in from. The fact it might be hallucinating its own value was not my first guess, because nothing else I've encountered does that in this context.
Quoted 3 lines
This wasn't an issue before we came to depend on cross compilers. Since we tend to need them more as compilation becomes more expensive, IMHO we should follow the practice of the embedded architectures.
That topic's a can of worms, but I point out that you always needed a cross compiler to bootstrap a new platform. :)
If you're going to support cross compiling at all, you might as well do it more or less consistently for all targets.
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Geert Uytterhoeven
maintainerQuoted 34 lines · Rob Landley
On Thursday 11 October 2007 11:26:07 am Finn Thain wrote:
My toolchains override the default prefix to just the target, resulting in "m68k-gcc". (It's shorter, and when you're creating a dozen toolchains having them all say -linux- in the middle of every command name gets a bit silly...)When it started complaining about "m68k-linux-gnu-gcc" (which is _not_ what my cross compiler is called) I spent half an hour tracking down where it was getting that name from and what exactly was going on. (Was my build script supplying the wrong name? Did something set an environment variable it shouldn't have? Did the gcc build suddenly reveal another strange buried corner case that made it revert to a default against explicit instructions _again_?)
When I found the surprising behavior that cost me time and effort to diagnose, I submitted a patch so it wouldn't confuse future developers the first time _they_ try to build m68k. (Yes, I think there might be such. Call me crazy.) I've seen "didn't specify any cross compiler" failures before, on arm and x86-64 and mips and sparc and so on. I've seen it in the linux kernel, in busybox, in uClibc, and in various gnu packages
with ./configureitis. This is the first time I've seen a package confidently decide for itself to use a compiler name that isn't in the $PATH, and especially the first time I've seen Linux do it. It cost me time to disagnose because it looks like it's getting aCROSS_COMPILEsetting from its environment somehow, and the logical thing to do is look at that environment (and the build scripts driving it, and the temp files) to see where such a thing might be leaking in from. The fact it might be hallucinating its own value was not my first guess, because nothing else I've encountered does that in this context.Quoted 3 lines
This wasn't an issue before we came to depend on cross compilers. Since we tend to need them more as compilation becomes more expensive, IMHO we should follow the practice of the embedded architectures.
Quoted 5 lines
That topic's a can of worms, but I point out that you always needed a cross compiler to bootstrap a new platform. :)
If you're going to support cross compiling at all, you might as well do it more or less consistently for all targets.
If your cross-compiler is called differently than the default on in arch/*/Makefile, what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 5 lines
If your cross-compiler is called differently than the default on in
arch/*/Makefile,
Part of the problem is that there is no compelling default. The name of the cross-compiler can vary depending on the chosen executable prefix or the chosen target tuple.
Let's say I create new cross toolchains for both m68k and powerpc. I use the "m68k-linux-gnu" to follow the m68k default, but let's assume powerpc users prefer their default "powerpc-linux" so I follow that too. The result is that I now have gcc's -B option working (or not working) in suprising ways too.
Uniformity is more helpful downstream than a different arbitrary default for each architecture. Debian should patch their default into their kernel source packages if they've standardised on cross compiler prefixes.
Quoted 5 lines
what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
But there is no problem with calling that (?). Rob's patch doesn't change this.
-f
Quoted 5 lines
Gr{oetje,eeting}s,
Geert
Geert Uytterhoeven
maintainerQuoted 17 lines · Finn Thain
Quoted 2 lines
If your cross-compiler is called differently than the default on in
arch/*/Makefile,Part of the problem is that there is no compelling default. The name of the cross-compiler can vary depending on the chosen executable prefix or the chosen target tuple.
Let's say I create new cross toolchains for both m68k and powerpc. I use the "m68k-linux-gnu" to follow the m68k default, but let's assume powerpc users prefer their default "powerpc-linux" so I follow that too. The result is that I now have gcc's -B option working (or not working) in suprising ways too.
Uniformity is more helpful downstream than a different arbitrary default for each architecture. Debian should patch their default into their kernel source packages if they've standardised on cross compiler prefixes.
Quoted 8 lines
Quoted 5 lines
what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
But there is no problem with calling that (?). Rob's patch doesn't change this.
But it makes life harder for the people who use it daily.
If the consensus is to not provide default cross compiler prefixes in arch/*/Makefile, fine for me, but IFF it's done for all architectures (i.e. check with the blackfin, h8300, mips, parisc, and xtensa people first).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 27 lines · Geert Uytterhoeven
Quoted 17 lines · Finn Thain
Quoted 2 lines
If your cross-compiler is called differently than the default on in
arch/*/Makefile,Part of the problem is that there is no compelling default. The name of the cross-compiler can vary depending on the chosen executable prefix or the chosen target tuple.
Let's say I create new cross toolchains for both m68k and powerpc. I use the "m68k-linux-gnu" to follow the m68k default, but let's assume powerpc users prefer their default "powerpc-linux" so I follow that too. The result is that I now have gcc's -B option working (or not working) in suprising ways too.
Uniformity is more helpful downstream than a different arbitrary default for each architecture. Debian should patch their default into their kernel source packages if they've standardised on cross compiler prefixes.
Quoted 8 lines
Quoted 5 lines
what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
But there is no problem with calling that (?). Rob's patch doesn't change this.
Quoted 6 lines
But it makes life harder for the people who use it daily.
If the consensus is to not provide default cross compiler prefixes in
arch/*/Makefile, fine for me, but IFF it's done for all architectures (i.e. check with the blackfin, h8300, mips, parisc, and xtensa people first).
Test if the expected gcc is available and set CROSS_COMPILE if it is present. Otherwise do not touch CROSS_COMPILE.
m68kgcc := $(shell "test if m68k-gcc is present and echo 'y' if so") ifeq ($(m68kgcc,y)
CROSS_COMPILE := m68k-foo
endif
Then everyone is happy.
parisc does something similar.
Sam
Geert Uytterhoeven
maintainerQuoted 38 lines · Sam Ravnborg
Quoted 27 lines · Geert Uytterhoeven
Quoted 17 lines · Finn Thain
Quoted 2 lines
If your cross-compiler is called differently than the default on in
arch/*/Makefile,Part of the problem is that there is no compelling default. The name of the cross-compiler can vary depending on the chosen executable prefix or the chosen target tuple.
Let's say I create new cross toolchains for both m68k and powerpc. I use the "m68k-linux-gnu" to follow the m68k default, but let's assume powerpc users prefer their default "powerpc-linux" so I follow that too. The result is that I now have gcc's -B option working (or not working) in suprising ways too.
Uniformity is more helpful downstream than a different arbitrary default for each architecture. Debian should patch their default into their kernel source packages if they've standardised on cross compiler prefixes.
Quoted 8 lines
Quoted 5 lines
what's the problem with calling?
make ARCH=myarch CROSS_COMPILE=my-cross-compile-prefx-
This has been working for +10 years on all non-ia32 platforms I ever worked on.
But there is no problem with calling that (?). Rob's patch doesn't change this.
Quoted 6 lines
But it makes life harder for the people who use it daily.
If the consensus is to not provide default cross compiler prefixes in
arch/*/Makefile, fine for me, but IFF it's done for all architectures (i.e. check with the blackfin, h8300, mips, parisc, and xtensa people first).Test if the expected gcc is available and set
CROSS_COMPILEif it is present. Otherwise do not touchCROSS_COMPILE.
Quoted 7 lines
m68kgcc := $(shell "test if m68k-gcc is present and echo 'y' if so") ifeq ($(m68kgcc,y)
CROSS_COMPILE:= m68k-foo
endifThen everyone is happy.
parisc does something similar.
64-bit parisc tests if /usr/bin/hppa64-linux-gnu- exists. If yes, it sets CROSS_COMPILE to hppa64-linux-gnu-. If no, it sets CROSS_COMPILE to hppa64-linux-
32-bit parisc unconditionally sets CROSS_COMPILE to hppa-linux-.
This still breaks Rob's setup if his compiler is called differently.
Anyway, here's a try to make it autodetect m68k-linux-gnu-gcc and m68k-linux-gcc. Perhaps it can be generalized in kbuild, to allow arch/*/Makefile to set a list of possible cross-compiler prefixes?
Subject: m68k: Improve cross-compiler autodetection
m68k: Improve cross-compiler autodetection
Set CROSS_COMPILE to m68k-linux-gnu- resp. m68k-linux-, but only if such a cross compiler is found in your $PATH
--- arch/m68k/Makefile | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
arch/m68k/Makefile +11 -1
@@ -22,7 +22,17 @@ LDFLAGS := -m m68kelf LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds ifneq ($(COMPILE_ARCH),$(ARCH)) # prefix for cross-compiling binaries - CROSS_COMPILE = m68k-linux-gnu- + m68k-linux-gnu-gcc := $(shell if [ `which m68k-linux-gnu-gcc` ]; then \ + echo y; fi) + ifeq ($(m68k-linux-gnu-gcc),y) + CROSS_COMPILE := m68k-linux-gnu- + else + m68k-linux-gcc := $(shell if [ `which m68k-linux-gcc` ]; then \ + echo y; fi) + ifeq ($(m68k-linux-gcc),y) + CROSS_COMPILE := m68k-linux- + endif + endif endif ifdef CONFIG_SUN3
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 7 lines · Geert Uytterhoeven
64-bit parisc tests if
/usr/bin/hppa64-linux-gnu-exists. If yes, it setsCROSS_COMPILEto hppa64-linux-gnu-. If no, it setsCROSS_COMPILEto hppa64-linux-32-bit parisc unconditionally sets
CROSS_COMPILEto hppa-linux-.This still breaks Rob's setup if his compiler is called differently.
Another thing to take into account is that kconfig was recently changed to save ARCH and CROSS_COMPILE in the .config file:
http://lwn.net/Articles/253889/
Presumably that means you'd only have to specify your arch and cross compiler during config, and then if you re-used that config it would re-use those settings. But the existing makefile discards anything that isn't explicitly overridden on the make command line at each stage of the build.
It seems to me any fix should only reset CROSS_COMPILE if there isn't already a value for it. (Otherwise there's a potentially subtle bug where a year from now you might have "m68k-linux-gnu-gcc" and "m68k-linux-gnu-pcc" and want to compare the results of building with the different compilers.)
I still lean towards considering any attempt to cross compile without setting CROSS_COMPILE an error, and not guessing at what the user meant. But perhaps that's just personal preference...
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 5 lines · Rob Landley
Quoted 4 lines · Geert Uytterhoeven
64-bit parisc tests if
/usr/bin/hppa64-linux-gnu-exists. If yes, it setsCROSS_COMPILEto hppa64-linux-gnu-. If no, it setsCROSS_COMPILEto hppa64-linux-
Quoted 8 lines
Quoted 3 lines
32-bit parisc unconditionally sets
CROSS_COMPILEto hppa-linux-.This still breaks Rob's setup if his compiler is called differently.
Another thing to take into account is that kconfig was recently changed to save ARCH and
CROSS_COMPILEin the .config file:
The patch is postponed one merge window.
It caused troubles I had not foreseen which needs some attention first. I plan to have it ready for next merge window.
Sam
Quoted 4 lines
Anyway, here's a try to make it autodetect m68k-linux-gnu-gcc and m68k-linux-gcc. Perhaps it can be generalized in kbuild, to allow
arch/*/Makefileto set a list of possible cross-compiler prefixes?
Here is my first try.
We only touch CROSS_COMPILE is empty and building for another arch.
I can obviously move crossgcc part of this to core kbuild. Any better name?
Sam
arch/m68k/Makefile +15 -6
@@ -13,17 +13,26 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compiling -COMPILE_ARCH = $(shell uname -m) +# usage: +# CROSS_COMPILE := $(call crossgcc, foo bar /usr/bin/) +# CROSS_COMPILE will be assinged the first prefix that point +# to a gcc in the path +crossgcc = $(word 1, $(foreach c,$(1), \ + $(shell set -e; \ + if (which $(strip $(c))$(CC)) > /dev/null 2>&1 ; then \ + echo $(c); \ + fi))) + +ifneq ($(SUBARCH),$(ARCH)) + ifeq ($(CROSS_COMPILE),) + CROSS_COMPILE := $(call crossgcc, m68k-linux-gnu-) + endif +endif # override top level makefile AS += -m68020 LDFLAGS := -m m68kelf LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds -ifneq ($(COMPILE_ARCH),$(ARCH)) - # prefix for cross-compiling binaries - CROSS_COMPILE = m68k-linux-gnu- -endif ifdef CONFIG_SUN3 LDFLAGS_vmlinux = -N
Quoted 22 lines · Sam Ravnborg
Quoted 3 lines
Anyway, here's a try to make it autodetect m68k-linux-gnu-gcc and m68k-linux-gcc. Perhaps it can be generalized in kbuild, to allow
arch/*/Makefileto set a list of possible cross-compiler prefixes?Here is my first try.
We only touchCROSS_COMPILEis empty and building for another arch.I can obviously move crossgcc part of this to core kbuild. Any better name?
Sam
arch/m68k/Makefile +0
-1@@ -13,17 +13,26 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compiling
arch/m68k/Makefile line 24
Quoted 10 lines
arch/m68k/Makefile +9
-1-COMPILE_ARCH = $(shell uname -m) +# usage: +# CROSS_COMPILE := $(call crossgcc, foo bar /usr/bin/) +# CROSS_COMPILE will be assinged the first prefix that point +# to a gcc in the path +crossgcc = $(word 1, $(foreach c,$(1), \ + $(shell set -e; \ + if (which $(strip $(c))$(CC)) > /dev/null 2>&1 ; then \ + echo $(c); \ + fi)))
Searching for common cross compiler prefixes. Cool.
What do you do if you want to use gcc as your host compiler, but m68k-pcc or arm-tcc as your target compiler? (I have no idea, CROSS_COMPILE=m68k- CC=pcc HOSTCC=gcc perhaps? Where does CC get set right now, anyway... Ah, top level Makefile:
CC = $(CROSS_COMPILE)gcc
That... should work. Odd and roundabout, but ok...
arch/m68k/Makefile line 30
Quoted 5 lines
arch/m68k/Makefile +5
-0+ifneq ($(SUBARCH),$(ARCH)) + ifeq ($(CROSS_COMPILE),) + CROSS_COMPILE := $(call crossgcc, m68k-linux-gnu-) + endif +endif
Other query:
If CROSS_COMPILE isn't set, and we iterate through all the standard prefixes but don't find a compiler, what's the right "fall off the end" behavior? If it falls back to using the host gcc, presumably the build will break if you feed your host gcc target flags it doesn't understand, but there are platforms where that sometimes doesn't seem to happen until the very end (building x86_64 on x86 for example)... Should the build just die with a "You are cross compiling, set CROSS_COMPILE".
I suppose there's the weird corner case where your hostcc is tcc and your targetcc is gcc...
Rob
Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Quoted 10 lines · Rob Landley
Quoted 9 lines · Sam Ravnborg
Quoted 3 lines
Anyway, here's a try to make it autodetect m68k-linux-gnu-gcc and m68k-linux-gcc. Perhaps it can be generalized in kbuild, to allow
arch/*/Makefileto set a list of possible cross-compiler prefixes?Here is my first try.
We only touchCROSS_COMPILEis empty and building for another arch.I can obviously move crossgcc part of this to core kbuild. Any better name?
find-crossgcc
Quoted 26 lines
Quoted 13 lines
Sam
arch/m68k/Makefile +0
-1@@ -13,17 +13,26 @@ # Copyright (C) 1994 by Hamish Macdonald # -# test for cross compilingarch/m68k/Makefile line 24
Quoted 10 lines
arch/m68k/Makefile +9
-1-COMPILE_ARCH = $(shell uname -m) +# usage: +# CROSS_COMPILE := $(call crossgcc, foo bar /usr/bin/) +# CROSS_COMPILE will be assinged the first prefix that point +# to a gcc in the path +crossgcc = $(word 1, $(foreach c,$(1), \ + $(shell set -e; \ + if (which $(strip $(c))$(CC)) > /dev/null 2>&1 ; then \ + echo $(c); \ + fi)))Searching for common cross compiler prefixes. Cool.
Quoted 7 lines
What do you do if you want to use gcc as your host compiler, but m68k-pcc or arm-tcc as your target compiler? (I have no idea, CROSS_COMPILE=m68k- CC=pcc HOSTCC=gcc perhaps? Where does CC get set right now, anyway... Ah, top level
Makefile:
CC = $(CROSS_COMPILE)gccThat... should work. Odd and roundabout, but ok...
I see no other way to do it - and it seems obvious since you guessed right.
Quoted 9 lines
arch/m68k/Makefile line 30
Quoted 6 lines
arch/m68k/Makefile +5
-0+ifneq ($(SUBARCH),$(ARCH)) + ifeq ($(CROSS_COMPILE),) + CROSS_COMPILE := $(call crossgcc, m68k-linux-gnu-) + endif +endifOther query:
Quoted 7 lines
If
CROSS_COMPILEisn't set, and we iterate through all the standard prefixes but don't find a compiler, what's the right "fall off the end" behavior? If it falls back to using the host gcc, presumably the build will break if you feed your host gcc target flags it doesn't understand, but there are platforms where that sometimes doesn't seem to happen until the very end (buildingx86_64on x86 for example)... Should the build just die with a "You are cross compiling, setCROSS_COMPILE".
No - that would be a bug. One may set up PATH sp gcc point to the cross-compile gcc. fallback to native (host) gcc is expected and fine.
Quoted 3 lines
I suppose there's the weird corner case where your hostcc is tcc and your targetcc is gcc...
I do not see why thats a problem - you just need to set both CC and HOSTCC.
Sam
Quoted 6 lines
Quoted 2 lines
2) suggested functionality makes it easy to do make
headers_installThis is something completely different (cfr. the other thread handling it). If `make
headers_install' doesn't need the cross compiler, it should not try to execute it.
This is obviously correct.
It happens that we execute gcc several times for just about any target due to the:
CFLAGS += $(call cc-option, xxx)
And refactoring the top-level Makefile to avoid this is on my TODO list. But it is a major crunch to do correct...
The primary objective to do so is btw not to solve this issue but more to get the top-level Makefile off the top-10 list of the most ureadable unmaitaninable unhackable code in the kernel.
Sam