systemd: needs kernel headers >= 3.7.
PATCH 1/1 systemd: needs kernel headers >= 3.7.
Systemd needs Linux headers >= 3.7 because it uses IFLA_GRE_FLOWINFO from linux/if_tunnel.h.
--- system/Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
system/Config.in +3 -3
@@ -96,12 +96,12 @@ config BR2_INIT_SYSTEMD depends on BR2_TOOLCHAIN_HAS_SSP depends on BR2_USE_MMU depends on !BR2_PREFER_STATIC_LIB - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 + depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7 select BR2_PACKAGE_SYSTEMD -comment 'systemd needs an (e)glibc toolchain, headers >= 3.0' +comment 'systemd needs an (e)glibc toolchain, headers >= 3.7' depends on !(BR2_TOOLCHAIN_USES_GLIBC \ - && BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0) + && BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7) config BR2_INIT_NONE bool "None"
Signature · 1 line
1.7.9.5
PATCH 1/1 systemd: enable build for supported architectures.
Systemd only supports the architectures defined in src/shared/architecture.h. So via a new parameter named BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS, we enable the build of this package only for those architectures.
Fixes http://autobuild.buildroot.net/results/bcc/bcce95eb0748505c0d62db21a6e420aae3c3181b/
--- package/systemd/Config.in | 9 ++++++++- system/Config.in | 2 +- 2 files changed, 9 insertions(+), 2 deletions(-)
package/systemd/Config.in +8 -1
@@ -1,7 +1,14 @@ +config BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS + bool + # see src/shared/architecture.h + default y if BR2_arm || BR2_armeb || BR2_i386 || BR2_mips || \ + BR2_mipsel || BR2_powerpc || BR2_sh4 || BR2_sh4eb || \ + BR2_sh4a || BR2_sh4aeb || BR2_sparc || BR2_x86_64 || \ + BR2_aarch64 || BR2_m68k + config BR2_PACKAGE_SYSTEMD bool "systemd" depends on BR2_INIT_SYSTEMD - depends on !BR2_avr32 # no epoll_create1 depends on BR2_LARGEFILE # util-linux depends on BR2_USE_WCHAR # util-linux depends on BR2_INET_IPV6
system/Config.in +1 -1
@@ -87,7 +87,7 @@ config BR2_INIT_SYSV config BR2_INIT_SYSTEMD bool "systemd" - depends on !BR2_avr32 # no epoll_create1 + depends on BR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS depends on BR2_TOOLCHAIN_USES_GLIBC depends on BR2_LARGEFILE depends on BR2_USE_WCHAR
Signature · 1 line
1.7.9.5
Thomas Petazzoni
AppliedPATCH 1/1 systemd: enable build for supported architectures.
Dear Eric Le Bihan,
Quoted 5 lines · Eric Le Bihan
Systemd only supports the architectures defined in
src/shared/architecture.h. So via a new parameter namedBR2_PACKAGE_SYSTEMD_ARCH_SUPPORTS, we enable the build of this package only for those architectures.
Quoted 7 lines
Fixes http://autobuild.buildroot.net/results/bcc/bcce95eb0748505c0d62db21a6e420aae3c3181b/
Signed-off-by Eric Le Bihan <[email protected]>--- package/systemd/Config.in | 9 ++++++++- system/Config.in | 2 +- 2 files changed, 9 insertions(+), 2 deletions(-)
Applied, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 systemd: needs kernel headers >= 3.7.
In reply to Eric Le BihanDear Eric Le Bihan,
Quoted 7 lines · Eric Le Bihan
Systemd needs Linux headers >= 3.7 because it uses
IFLA_GRE_FLOWINFOfromlinux/if_tunnel.h.Signed-off-by Eric Le Bihan <[email protected]>--- system/Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Are you sure Linux headers >= 3.7 are sufficient? I'm looking at the build failure at
http://autobuild.buildroot.org/results/ad3/ad3b4003dc50582a493f1156234d83652104a6bf/build-end.log,
and it looks like missing kernel definitions, even though the toolchain apparently uses 3.7 kernel headers, as far as I can see.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 systemd: needs kernel headers >= 3.7.
Eric, Thomas, All,
On 2014-03-29 09:35 +0100, Thomas Petazzoni spake thusly:
Quoted 9 lines · Eric Le Bihan
Quoted 7 lines
Systemd needs Linux headers >= 3.7 because it uses
IFLA_GRE_FLOWINFOfromlinux/if_tunnel.h.Signed-off-by Eric Le Bihan <[email protected]>--- system/Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Quoted 5 lines
Are you sure Linux headers >= 3.7 are sufficient? I'm looking at the build failure at
http://autobuild.buildroot.org/results/ad3/ad3b4003dc50582a493f1156234d83652104a6bf/build-end.log,
and it looks like missing kernel definitions, even though the toolchain apparently uses 3.7 kernel headers, as far as I can see.
No, they were introduced in 3.8.
What's confusing is that the changesets were done on a v3.7-rc* tree, so when one git-blames the affected file, checkouts the changeset with the chagnes, and looks at Makefile, one will see 3.7-rc1. But they eventually landed in 3.8.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 systemd: needs kernel headers >= 3.7.
Yann E., Thomas, All,
Quoted 18 lines · Yann E. MORIN
Eric, Thomas, All,
On 2014-03-29 09:35 +0100, Thomas Petazzoni spake thusly:
Quoted 9 lines · Eric Le Bihan
Quoted 7 lines
Systemd needs Linux headers >= 3.7 because it uses
IFLA_GRE_FLOWINFOfromlinux/if_tunnel.h.Signed-off-by Eric Le Bihan <[email protected]>--- system/Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)Quoted 5 lines
Are you sure Linux headers >= 3.7 are sufficient? I'm looking at the build failure at
http://autobuild.buildroot.org/results/ad3/ad3b4003dc50582a493f1156234d83652104a6bf/build-end.log,
and it looks like missing kernel definitions, even though the toolchain apparently uses 3.7 kernel headers, as far as I can see.
Quoted 6 lines
No, they were introduced in 3.8.
What's confusing is that the changesets were done on a v3.7-rc* tree, so when one git-blames the affected file, checkouts the changeset with the chagnes, and looks at
Makefile, one will see 3.7-rc1. But they eventually landed in 3.8.
Thanks for clarifying!
BTW, why is it only possible to use an external toolchain for AArch64, and not a Buildroot one? I've also noticied that the recently released Linaro 14.03 still uses Linux headers 3.7...
Best regards,
ELB
PATCH 1/1 systemd: needs kernel headers >= 3.7.
Dear Eric Le Bihan,
Quoted 3 lines · Eric Le Bihan
BTW, why is it only possible to use an external toolchain for AArch64, and not a Buildroot one? I've also noticied that the recently released Linaro 14.03 still uses Linux headers 3.7...
Because when I added AArch64 support in Buildroot, the support for it was not yet in mainline gcc/binutils/gdb/glibc. It was still in the process of being merged.
Now that it has been done, it should be possible to add AArch64 support in the internal toolchain backend, without too much troubles, hopefully.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 systemd: needs kernel headers >= 3.7.
In reply to Yann E. MORINQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 5 lines
Are you sure Linux headers >= 3.7 are sufficient? I'm looking at the build failure at
http://autobuild.buildroot.org/results/ad3/ad3b4003dc50582a493f1156234d83652104a6bf/build-end.log,
and it looks like missing kernel definitions, even though the toolchain apparently uses 3.7 kernel headers, as far as I can see.
Quoted 6 lines
No, they were introduced in 3.8.
What's confusing is that the changesets were done on a v3.7-rc* tree, so when one git-blames the affected file, checkouts the changeset with the chagnes, and looks at
Makefile, one will see 3.7-rc1. But they eventually landed in 3.8.
Old mail, but I only got to read it now.
You need to use git describe --contains <hash> to see the first git tag containing that change, E.G.:
git describe --match v3.\* --contains 0974658da47cb399b76794057823bf3cd22acf3 v3.8-rc1~139^2~384
(I have a linux-next remote here, so it would match on the next tag instead unless I use --match).
E.G. this was merged 139 commits before 3.8-rc1 was tagged.
Signature · 1 line
Bye, Peter Korsgaard