Skip to contentSkip to conversation

systemd: needs kernel headers >= 3.7.

PATCH New Eric Le Bihan 4 participants 8 messages Mar 28, 2014 – Jul 29, 2014

lore
Share & tools
lore
#0 lore raw

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
index e8f1ed6..54aac11 100644
@@ -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
#1 lore raw

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
index 838e13e..095fee0 100644
@@ -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
index 54aac11..0a00188 100644
@@ -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
#2 lore raw

PATCH 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 named BR2_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/

---
 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
#3 lore raw

PATCH 1/1 systemd: needs kernel headers >= 3.7.

In reply to Eric Le Bihan

Dear Eric Le Bihan,

Quoted 7 lines · Eric Le Bihan

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(-)

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
#4 lore raw

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_FLOWINFO from linux/if_tunnel.h.

---
 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.  |
'------------------------------^-------^------------------^--------------------'
#5 lore raw

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_FLOWINFO from linux/if_tunnel.h.

---
 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

#6 lore raw

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
#7 lore raw

PATCH 1/1 systemd: needs kernel headers >= 3.7.

In reply to Yann E. MORIN
Quoted 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