* [Buildroot] External toolchain support improvements
@ 2008-10-30 8:45 Thomas Petazzoni
2008-10-31 18:42 ` hartleys
` (4 more replies)
0 siblings, 5 replies; 12+ messages in thread
From: Thomas Petazzoni @ 2008-10-30 8:45 UTC (permalink / raw)
To: buildroot
Improve external toolchain support
* Do not put kernel-headers in the dependencies of BASE_TARGETS in
the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
are already supposed to be part of the external toolchain, so
there's no need to download, extract and install them.
* In the configuration system, don't display the kernel headers
version selection list when an external toolchain is selected. This
is implemented by moving the source
"toolchain/kernel-headers/Config.in" inside the if
BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2.
* Change the description and help message of the BR2_LARGEFILE,
BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
toolchain/external-toolchain/Config.in. In the case of an external
toolchain, the semantic of these options is not to enable large
file support, IPV6 or RPC (since the toolchain is already compiled,
it has been decided previously). Their semantic is to let Buildroot
know about the characteristics of the external toolchain being
used.
As an improvement, we could guess these values automatically:
- for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in
bits/uClibc_config.h in the libc headers directory.
- for BR2_INET_RPC, look at the value of __UCLIBC_HAS_RPC__ in the
same file
- for BR2_INET_IPV6, look at the value of __UCLIBC_HAS_IPV6__ in
the same file
- for BR2_SOFT_FLOAT, look at the output of $(CC) -v 2>&1 | grep
-- "--with-float=soft"
But I'm not sure how this would be possible, since these values are
used at configuration-time by other configuration options, not only
at build time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Makefile | 2 +-
toolchain/Config.in.2 | 3 +--
toolchain/external-toolchain/Config.in | 23 ++++++++++-------------
3 files changed, 12 insertions(+), 16 deletions(-)
Index: buildroot/Makefile
===================================================================
--- buildroot.orig/Makefile
+++ buildroot/Makefile
@@ -202,7 +202,7 @@
ifeq ($(BR2_TOOLCHAIN_SOURCE),y)
BASE_TARGETS:=uclibc-configured binutils cross_compiler uclibc-target-utils kernel-headers
else
-BASE_TARGETS:=uclibc kernel-headers
+BASE_TARGETS:=uclibc
endif
TARGETS:=
Index: buildroot/toolchain/Config.in.2
===================================================================
--- buildroot.orig/toolchain/Config.in.2
+++ buildroot/toolchain/Config.in.2
@@ -1,8 +1,7 @@
#
-source "toolchain/kernel-headers/Config.in"
-
if BR2_TOOLCHAIN_SOURCE
+source "toolchain/kernel-headers/Config.in"
source "toolchain/uClibc/Config.in"
source "toolchain/binutils/Config.in"
source "toolchain/gcc/Config.in"
Index: buildroot/toolchain/external-toolchain/Config.in
===================================================================
--- buildroot.orig/toolchain/external-toolchain/Config.in
+++ buildroot/toolchain/external-toolchain/Config.in
@@ -69,32 +69,29 @@
endchoice
config BR2_LARGEFILE
- bool "Enable large file (files > 2 GB) support?"
+ bool "Toolchain supports large files (> 2 GB) ?"
depends on !BR2_cris
default y
help
- Enable large file (files > 2 GB) support
+ Set this option if the external toolchain supports large
+ files (> 2 GB)
+
config BR2_INET_IPV6
- bool "Enable IPv6"
+ bool "Toolchain supports IPv6 ?"
help
- Enable IPv6.
+ Set this option if the external toolchain supports IPv6.
config BR2_INET_RPC
- bool "Enable RPC"
+ bool "Toolchain supports RPC ?"
help
- Enable RPC. RPC support is needed for nfs.
+ Set this option if the external toolchain supports RPC.
config BR2_SOFT_FLOAT
- bool "Use software floating point by default"
+ bool "Toolchain supports soft float ?"
depends on BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_powerpc
help
- If your target CPU does not have a Floating Point Unit (FPU) or a
- kernel FPU emulator, but you still wish to support floating point
- functions, then everything will need to be compiled with soft
- floating point support (-msoft-float).
-
- Most people will answer N.
+ Set this option if the external toolchain supports soft float.
config BR2_TARGET_OPTIMIZATION
string "Target Optimizations"
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
@ 2008-10-31 18:42 ` hartleys
2008-11-03 8:31 ` Thomas Petazzoni
2008-10-31 19:21 ` Grant Likely
` (3 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: hartleys @ 2008-10-31 18:42 UTC (permalink / raw)
To: buildroot
On Thursday, October 30, 2008 1:45 AM, Thomas Petazzoni wrote:
> Improve external toolchain support
>
> * Do not put kernel-headers in the dependencies of BASE_TARGETS in
> the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
> are already supposed to be part of the external toolchain, so
> there's no need to download, extract and install them.
What are the side effects if you use an external toolchain that was
built with a given kernel version, say 2.6.20.4, but use a newer kernel,
say 2.6.27.3?
Thanks,
Hartley
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
2008-10-31 18:42 ` hartleys
@ 2008-10-31 19:21 ` Grant Likely
2008-11-03 10:15 ` Peter Korsgaard
` (2 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Grant Likely @ 2008-10-31 19:21 UTC (permalink / raw)
To: buildroot
On Thu, Oct 30, 2008 at 2:45 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Improve external toolchain support
>
> * Do not put kernel-headers in the dependencies of BASE_TARGETS in
> the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
> are already supposed to be part of the external toolchain, so
> there's no need to download, extract and install them.
>
> * In the configuration system, don't display the kernel headers
> version selection list when an external toolchain is selected. This
> is implemented by moving the source
> "toolchain/kernel-headers/Config.in" inside the if
> BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2.
>
> * Change the description and help message of the BR2_LARGEFILE,
> BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
> toolchain/external-toolchain/Config.in. In the case of an external
> toolchain, the semantic of these options is not to enable large
> file support, IPV6 or RPC (since the toolchain is already compiled,
> it has been decided previously). Their semantic is to let Buildroot
> know about the characteristics of the external toolchain being
> used.
>
> As an improvement, we could guess these values automatically:
>
> - for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in
> bits/uClibc_config.h in the libc headers directory.
>
> - for BR2_INET_RPC, look at the value of __UCLIBC_HAS_RPC__ in the
> same file
>
> - for BR2_INET_IPV6, look at the value of __UCLIBC_HAS_IPV6__ in
> the same file
>
> - for BR2_SOFT_FLOAT, look at the output of $(CC) -v 2>&1 | grep
> -- "--with-float=soft"
>
> But I'm not sure how this would be possible, since these values are
> used at configuration-time by other configuration options, not only
> at build time.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Makefile | 2 +-
> toolchain/Config.in.2 | 3 +--
> toolchain/external-toolchain/Config.in | 23 ++++++++++-------------
> 3 files changed, 12 insertions(+), 16 deletions(-)
>
> Index: buildroot/Makefile
> ===================================================================
> --- buildroot.orig/Makefile
> +++ buildroot/Makefile
> @@ -202,7 +202,7 @@
> ifeq ($(BR2_TOOLCHAIN_SOURCE),y)
> BASE_TARGETS:=uclibc-configured binutils cross_compiler uclibc-target-utils kernel-headers
> else
> -BASE_TARGETS:=uclibc kernel-headers
> +BASE_TARGETS:=uclibc
> endif
> TARGETS:=
>
> Index: buildroot/toolchain/Config.in.2
> ===================================================================
> --- buildroot.orig/toolchain/Config.in.2
> +++ buildroot/toolchain/Config.in.2
> @@ -1,8 +1,7 @@
> #
>
> -source "toolchain/kernel-headers/Config.in"
> -
> if BR2_TOOLCHAIN_SOURCE
> +source "toolchain/kernel-headers/Config.in"
> source "toolchain/uClibc/Config.in"
> source "toolchain/binutils/Config.in"
> source "toolchain/gcc/Config.in"
> Index: buildroot/toolchain/external-toolchain/Config.in
> ===================================================================
> --- buildroot.orig/toolchain/external-toolchain/Config.in
> +++ buildroot/toolchain/external-toolchain/Config.in
> @@ -69,32 +69,29 @@
> endchoice
>
> config BR2_LARGEFILE
> - bool "Enable large file (files > 2 GB) support?"
> + bool "Toolchain supports large files (> 2 GB) ?"
> depends on !BR2_cris
> default y
> help
> - Enable large file (files > 2 GB) support
> + Set this option if the external toolchain supports large
> + files (> 2 GB)
> +
>
> config BR2_INET_IPV6
> - bool "Enable IPv6"
> + bool "Toolchain supports IPv6 ?"
> help
> - Enable IPv6.
> + Set this option if the external toolchain supports IPv6.
>
> config BR2_INET_RPC
> - bool "Enable RPC"
> + bool "Toolchain supports RPC ?"
> help
> - Enable RPC. RPC support is needed for nfs.
> + Set this option if the external toolchain supports RPC.
>
> config BR2_SOFT_FLOAT
> - bool "Use software floating point by default"
> + bool "Toolchain supports soft float ?"
> depends on BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_powerpc
> help
> - If your target CPU does not have a Floating Point Unit (FPU) or a
> - kernel FPU emulator, but you still wish to support floating point
> - functions, then everything will need to be compiled with soft
> - floating point support (-msoft-float).
> -
> - Most people will answer N.
> + Set this option if the external toolchain supports soft float.
>
> config BR2_TARGET_OPTIMIZATION
> string "Target Optimizations"
>
>
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers and embedded Linux development,
> consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-31 18:42 ` hartleys
@ 2008-11-03 8:31 ` Thomas Petazzoni
2008-11-03 15:52 ` hartleys
0 siblings, 1 reply; 12+ messages in thread
From: Thomas Petazzoni @ 2008-11-03 8:31 UTC (permalink / raw)
To: buildroot
Le Fri, 31 Oct 2008 14:42:14 -0400,
"hartleys" <hartleys@visionengravers.com> a ?crit :
> What are the side effects if you use an external toolchain that was
> built with a given kernel version, say 2.6.20.4, but use a newer
> kernel, say 2.6.27.3?
The kernel <-> userspace interface is backward compatible. So if you
use a toolchain that was compiled against the headers of kernel
2.6.20.4 and run the binaries under 2.6.27.3, them it will work
perfectly fine. The only thing is that you won't be able to use the new
system calls, data structures, headers, defines, that have been added
in the kernel between 2.6.20.4 and 2.6.27.3.
The reverse side: if you generate binaries with a toolchain that has
been compiled against the headers of kernel 2.6.27.3 and run it on a
2.6.20.4 kernel, then there are two cases :
* You don't use any of the new features of the kernel <-> userspace
interface added between 2.6.20.4 and 2.6.27.3 : everything will work
correctly ;
* You use one of these new features: your binary might fail to run
properly (for example if they use a new system call, that isn't
available in your kernel).
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
2008-10-31 18:42 ` hartleys
2008-10-31 19:21 ` Grant Likely
@ 2008-11-03 10:15 ` Peter Korsgaard
2008-11-03 10:18 ` Peter Korsgaard
2008-11-03 12:48 ` Shinya Kuribayashi
4 siblings, 0 replies; 12+ messages in thread
From: Peter Korsgaard @ 2008-11-03 10:15 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Improve external toolchain support
Thomas> * Do not put kernel-headers in the dependencies of BASE_TARGETS in
Thomas> the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
Thomas> are already supposed to be part of the external toolchain, so
Thomas> there's no need to download, extract and install them.
Sounds good.
Thomas> * In the configuration system, don't display the kernel headers
Thomas> version selection list when an external toolchain is selected. This
Thomas> is implemented by moving the source
Thomas> "toolchain/kernel-headers/Config.in" inside the if
Thomas> BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2.
And this too.
Thomas> * Change the description and help message of the BR2_LARGEFILE,
Thomas> BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
Thomas> toolchain/external-toolchain/Config.in. In the case of an external
Thomas> toolchain, the semantic of these options is not to enable large
Thomas> file support, IPV6 or RPC (since the toolchain is already compiled,
Thomas> it has been decided previously). Their semantic is to let Buildroot
Thomas> know about the characteristics of the external toolchain being
Thomas> used.
Exactly.
Thomas> As an improvement, we could guess these values automatically:
Thomas> - for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in
Thomas> bits/uClibc_config.h in the libc headers directory.
This would only work for external toolchains using uclibc - I guess
the main reason for using an external toolchain is to not use uclibc?
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
` (2 preceding siblings ...)
2008-11-03 10:15 ` Peter Korsgaard
@ 2008-11-03 10:18 ` Peter Korsgaard
2008-11-03 12:48 ` Shinya Kuribayashi
4 siblings, 0 replies; 12+ messages in thread
From: Peter Korsgaard @ 2008-11-03 10:18 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Improve external toolchain support
Thanks, committed as r23908.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
` (3 preceding siblings ...)
2008-11-03 10:18 ` Peter Korsgaard
@ 2008-11-03 12:48 ` Shinya Kuribayashi
2008-11-03 12:58 ` Peter Korsgaard
4 siblings, 1 reply; 12+ messages in thread
From: Shinya Kuribayashi @ 2008-11-03 12:48 UTC (permalink / raw)
To: buildroot
Thomas Petazzoni wrote:
> * Change the description and help message of the BR2_LARGEFILE,
> BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
> toolchain/external-toolchain/Config.in. In the case of an external
> toolchain, the semantic of these options is not to enable large
> file support, IPV6 or RPC (since the toolchain is already compiled,
> it has been decided previously). Their semantic is to let Buildroot
> know about the characteristics of the external toolchain being
> used.
[snip]
> Index: buildroot/toolchain/external-toolchain/Config.in
> ===================================================================
> --- buildroot.orig/toolchain/external-toolchain/Config.in
> +++ buildroot/toolchain/external-toolchain/Config.in
> @@ -69,32 +69,29 @@
> endchoice
>
> config BR2_LARGEFILE
> - bool "Enable large file (files > 2 GB) support?"
> + bool "Toolchain supports large files (> 2 GB) ?"
> depends on !BR2_cris
> default y
> help
> - Enable large file (files > 2 GB) support
> + Set this option if the external toolchain supports large
> + files (> 2 GB)
> +
>
> config BR2_INET_IPV6
> - bool "Enable IPv6"
> + bool "Toolchain supports IPv6 ?"
> help
> - Enable IPv6.
> + Set this option if the external toolchain supports IPv6.
>
> config BR2_INET_RPC
> - bool "Enable RPC"
> + bool "Toolchain supports RPC ?"
> help
> - Enable RPC. RPC support is needed for nfs.
> + Set this option if the external toolchain supports RPC.
>
> config BR2_SOFT_FLOAT
> - bool "Use software floating point by default"
> + bool "Toolchain supports soft float ?"
> depends on BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_powerpc
> help
> - If your target CPU does not have a Floating Point Unit (FPU) or a
> - kernel FPU emulator, but you still wish to support floating point
> - functions, then everything will need to be compiled with soft
> - floating point support (-msoft-float).
> -
> - Most people will answer N.
> + Set this option if the external toolchain supports soft float.
>
> config BR2_TARGET_OPTIMIZATION
> string "Target Optimizations"
Why did you change these help text? The previous messages seemed to be
better, at least for me. These options should be enabled based on what
we want to do, not based on the toolchain's capabilities.
I know that we share the same recognition of course, but current
"Toolchain supports XXX?" feels somewhat misleading.
Thanks,
Shinya
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-11-03 12:48 ` Shinya Kuribayashi
@ 2008-11-03 12:58 ` Peter Korsgaard
2008-11-03 13:25 ` Shinya Kuribayashi
0 siblings, 1 reply; 12+ messages in thread
From: Peter Korsgaard @ 2008-11-03 12:58 UTC (permalink / raw)
To: buildroot
>>>>> "Shinya" == Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> writes:
Hi,
>> * Change the description and help message of the BR2_LARGEFILE,
>> BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
>> toolchain/external-toolchain/Config.in. In the case of an external
>> toolchain, the semantic of these options is not to enable large
>> file support, IPV6 or RPC (since the toolchain is already compiled,
>> it has been decided previously). Their semantic is to let Buildroot
>> know about the characteristics of the external toolchain being
>> used.
Shinya> [snip]
>> Index: buildroot/toolchain/external-toolchain/Config.in
>> ===================================================================
>> --- buildroot.orig/toolchain/external-toolchain/Config.in
>> +++ buildroot/toolchain/external-toolchain/Config.in
>> @@ -69,32 +69,29 @@
>> endchoice
>>
>> config BR2_LARGEFILE
>> - bool "Enable large file (files > 2 GB) support?"
>> + bool "Toolchain supports large files (> 2 GB) ?"
>> depends on !BR2_cris
>> default y
>> help
>> - Enable large file (files > 2 GB) support
>> + Set this option if the external toolchain supports large
>> + files (> 2 GB)
>> +
>>
>> config BR2_INET_IPV6
>> - bool "Enable IPv6"
>> + bool "Toolchain supports IPv6 ?"
>> help
>> - Enable IPv6.
>> + Set this option if the external toolchain supports IPv6.
>>
>> config BR2_INET_RPC
>> - bool "Enable RPC"
>> + bool "Toolchain supports RPC ?"
>> help
>> - Enable RPC. RPC support is needed for nfs.
>> + Set this option if the external toolchain supports RPC.
>>
>> config BR2_SOFT_FLOAT
>> - bool "Use software floating point by default"
>> + bool "Toolchain supports soft float ?"
>> depends on BR2_arm || BR2_armeb || BR2_mips || BR2_mipsel || BR2_powerpc
>> help
>> - If your target CPU does not have a Floating Point Unit (FPU) or a
>> - kernel FPU emulator, but you still wish to support floating point
>> - functions, then everything will need to be compiled with soft
>> - floating point support (-msoft-float).
>> -
>> - Most people will answer N.
>> + Set this option if the external toolchain supports soft float.
>>
>> config BR2_TARGET_OPTIMIZATION
>> string "Target Optimizations"
Shinya> Why did you change these help text? The previous messages
Shinya> seemed to be better, at least for me. These options should
Shinya> be enabled based on what we want to do, not based on the
Shinya> toolchain's capabilities.
No, these are settings for the external toolchain, E.G. configuration
options you have to set to match whatever your external toolchain has.
Don't get misled by the fact that we have the same configuration
variables (with different help text) for the normal buildroot
toolchain.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-11-03 12:58 ` Peter Korsgaard
@ 2008-11-03 13:25 ` Shinya Kuribayashi
2008-11-03 14:03 ` Peter Korsgaard
0 siblings, 1 reply; 12+ messages in thread
From: Shinya Kuribayashi @ 2008-11-03 13:25 UTC (permalink / raw)
To: buildroot
Peter Korsgaard wrote:
> No, these are settings for the external toolchain, E.G. configuration
> options you have to set to match whatever your external toolchain has.
Sure.
> Don't get misled by the fact that we have the same configuration
> variables (with different help text) for the normal buildroot
> toolchain.
I know that, of course.
This patch (and probably your comments) seems to overlook toolchains
built with _multi libraries_. Please do not assume toolchain's default
options or default configurations, especially when we talk about
external toolchain support.
Thanks,
Shinya
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-11-03 13:25 ` Shinya Kuribayashi
@ 2008-11-03 14:03 ` Peter Korsgaard
0 siblings, 0 replies; 12+ messages in thread
From: Peter Korsgaard @ 2008-11-03 14:03 UTC (permalink / raw)
To: buildroot
>>>>> "Shinya" == Shinya Kuribayashi <skuribay@ruby.dti.ne.jp> writes:
Shinya> This patch (and probably your comments) seems to overlook
Shinya> toolchains built with _multi libraries_. Please do not
Shinya> assume toolchain's default options or default configurations,
Shinya> especially when we talk about external toolchain support.
Ok, I don't personally use either ext toolchain or multilib, but
patches are welcome.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-11-03 8:31 ` Thomas Petazzoni
@ 2008-11-03 15:52 ` hartleys
2008-11-03 23:51 ` Markus Heidelberg
0 siblings, 1 reply; 12+ messages in thread
From: hartleys @ 2008-11-03 15:52 UTC (permalink / raw)
To: buildroot
On Monday, November 03, 2008 1:31 AM, Thomas Petazzoni wrote:
>> What are the side effects if you use an external toolchain that was
>> built with a given kernel version, say 2.6.20.4, but use a newer
>> kernel, say 2.6.27.3?
>
> The kernel <-> userspace interface is backward compatible. So if you
> use a toolchain that was compiled against the headers of kernel
> 2.6.20.4 and run the binaries under 2.6.27.3, them it will work
> perfectly fine. The only thing is that you won't be able to use the
> new system calls, data structures, headers, defines, that have been
> added in the kernel between 2.6.20.4 and 2.6.27.3.
>
> The reverse side: if you generate binaries with a toolchain that has
> been compiled against the headers of kernel 2.6.27.3 and run it on a
> 2.6.20.4 kernel, then there are two cases :
>
> * You don't use any of the new features of the kernel <-> userspace
> interface added between 2.6.20.4 and 2.6.27.3 : everything will
work
> correctly ;
>
> * You use one of these new features: your binary might fail to run
> properly (for example if they use a new system call, that isn't
> available in your kernel).
Thanks for the clarification.
BTW, something is now broken with svn revision 23911 using an external
toolchain.
I just did a "svn up; make menuconfig; make" and I get the following
errors right when the build starts.
Checking build system dependencies:
BUILDROOT_DL_DIR clean: Ok
CC clean: Ok
CXX clean: Ok
CPP clean: Ok
CFLAGS clean: Ok
INCLUDES clean: Ok
CXXFLAGS clean: Ok
which installed: Ok
sed works: Ok (/bin/sed)
GNU make version '3.81': Ok
C compiler '/usr/bin/gcc'
C compiler version '4.1.2': Ok
C++ compiler '/usr/bin/g++'
C++ compiler version '4.1.2': Ok
awk installed: Ok
bison installed: Ok
flex installed: Ok
gettext installed: Ok
makeinfo installed: Ok
Build system dependencies: Ok
rm -rf
/home/bigguiness/buildroot/project_build_arm/ep9307/buildroot-config
mkdir -p /home/bigguiness/buildroot/project_build_arm/ep9307
cp -dpRf package/config/buildroot-config
/home/bigguiness/buildroot/project_build_arm/ep9307/buildroot-config
wget --passive-ftp -nd -P /home/bigguiness/buildroot/dl
"http://www.kernel.org/pub/"/linux/kernel/v2.6//linux-...tar.bz2
--08:47:11--
http://www.kernel.org/pub//linux/kernel/v2.6//linux-...tar.bz2
=> `/home/bigguiness/buildroot/dl/linux-...tar.bz2'
Resolving www.kernel.org... 204.152.191.5, 204.152.191.37
Connecting to www.kernel.org|204.152.191.5|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
08:47:11 ERROR 404: Not Found.
make: *** [/home/bigguiness/buildroot/dl/linux-...tar.bz2] Error 1
I can't figure out what .mk is trying to download "linux-...tar.bz2".
Any ideas?
Thanks,
Hartley
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Buildroot] External toolchain support improvements
2008-11-03 15:52 ` hartleys
@ 2008-11-03 23:51 ` Markus Heidelberg
0 siblings, 0 replies; 12+ messages in thread
From: Markus Heidelberg @ 2008-11-03 23:51 UTC (permalink / raw)
To: buildroot
hartleys, 03.11.2008:
> BTW, something is now broken with svn revision 23911 using an external
> toolchain.
>
> I just did a "svn up; make menuconfig; make" and I get the following
> errors right when the build starts.
>
> wget --passive-ftp -nd -P /home/bigguiness/buildroot/dl
> "http://www.kernel.org/pub/"/linux/kernel/v2.6//linux-...tar.bz2
> --08:47:11--
> http://www.kernel.org/pub//linux/kernel/v2.6//linux-...tar.bz2
> => `/home/bigguiness/buildroot/dl/linux-...tar.bz2'
> Resolving www.kernel.org... 204.152.191.5, 204.152.191.37
> Connecting to www.kernel.org|204.152.191.5|:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 08:47:11 ERROR 404: Not Found.
>
> make: *** [/home/bigguiness/buildroot/dl/linux-...tar.bz2] Error 1
>
>
> I can't figure out what .mk is trying to download "linux-...tar.bz2".
> Any ideas?
Some odd configuration?
grep WGET target/linux/Makefile.in*
Find out which one is used and backtrace the variable. Probably some kernel
version number variables are empty resulting in .. instead of 2.6.25
Markus
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-11-03 23:51 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-30 8:45 [Buildroot] External toolchain support improvements Thomas Petazzoni
2008-10-31 18:42 ` hartleys
2008-11-03 8:31 ` Thomas Petazzoni
2008-11-03 15:52 ` hartleys
2008-11-03 23:51 ` Markus Heidelberg
2008-10-31 19:21 ` Grant Likely
2008-11-03 10:15 ` Peter Korsgaard
2008-11-03 10:18 ` Peter Korsgaard
2008-11-03 12:48 ` Shinya Kuribayashi
2008-11-03 12:58 ` Peter Korsgaard
2008-11-03 13:25 ` Shinya Kuribayashi
2008-11-03 14:03 ` Peter Korsgaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox