diff mbox

systemd: needs kernel headers >= 3.7.

Message ID 1396024266-6662-1-git-send-email-eric.le.bihan.dev@free.fr
State Superseded
Headers show

Commit Message

Eric Le Bihan March 28, 2014, 4:31 p.m. UTC
Systemd needs Linux headers >= 3.7 because it uses IFLA_GRE_FLOWINFO
from linux/if_tunnel.h.

Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
---
 system/Config.in |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Thomas Petazzoni March 29, 2014, 8:35 a.m. UTC | #1
Dear Eric Le Bihan,

On Fri, 28 Mar 2014 17:31:05 +0100, Eric Le Bihan wrote:
> Systemd needs Linux headers >= 3.7 because it uses IFLA_GRE_FLOWINFO
> from linux/if_tunnel.h.
> 
> Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> ---
>  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
Yann E. MORIN March 29, 2014, 9:32 a.m. UTC | #2
Eric, Thomas, All,

On 2014-03-29 09:35 +0100, Thomas Petazzoni spake thusly:
> On Fri, 28 Mar 2014 17:31:05 +0100, Eric Le Bihan wrote:
> > Systemd needs Linux headers >= 3.7 because it uses IFLA_GRE_FLOWINFO
> > from linux/if_tunnel.h.
> > 
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > ---
> >  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.

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.
Eric Le Bihan March 31, 2014, 9:40 a.m. UTC | #3
Yann E., Thomas, All,
On Sat, Mar 29, 2014 at 10:32:08AM +0100, Yann E. MORIN wrote:
> Eric, Thomas, All,
>
> On 2014-03-29 09:35 +0100, Thomas Petazzoni spake thusly:
> > On Fri, 28 Mar 2014 17:31:05 +0100, Eric Le Bihan wrote:
> > > Systemd needs Linux headers >= 3.7 because it uses IFLA_GRE_FLOWINFO
> > > from linux/if_tunnel.h.
> > >
> > > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > > ---
> > >  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.
>
> 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
Thomas Petazzoni March 31, 2014, 9:46 a.m. UTC | #4
Dear Eric Le Bihan,

On Mon, 31 Mar 2014 11:40:57 +0200, Eric Le Bihan wrote:

> 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
Peter Korsgaard July 29, 2014, 2:14 p.m. UTC | #5
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

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

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.
diff mbox

Patch

diff --git a/system/Config.in b/system/Config.in
index e8f1ed6..54aac11 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -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"