* [meta-oe][PATCH] efivar: fix zero initializer compiler error
@ 2016-01-19 10:45 Alexandru But
2016-01-29 18:01 ` Martin Jansa
0 siblings, 1 reply; 8+ messages in thread
From: Alexandru But @ 2016-01-19 10:45 UTC (permalink / raw)
To: openembedded-devel
Patch based on commit a3606c0:
Sometimes the compiler doesn't like { 0,} as an initializer
Signed-off-by: Alexandru But <alexandru.but@ni.com>
---
...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
new file mode 100644
index 0000000..68cabd6
--- /dev/null
+++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
@@ -0,0 +1,42 @@
+From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
+From: Peter Jones <pjones@redhat.com>
+Date: Tue, 14 Jul 2015 09:33:54 -0400
+Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
+ initializer...
+
+Because it really wants to be { {0, },} or something, and sometimes the
+compiler, knowing full well what we're trying to do, likes to complain
+about the rigor applied to our technique in doing it.
+
+memset() the struct ifreq to 0 instead so I don't need to figure out its
+internal structure just to zero it out.
+
+Resolves #28
+
+Signed-off-by: Peter Jones <pjones@redhat.com>
+---
+ src/linux.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/src/linux.c b/src/linux.c
+index 57f71f3..817b8e6 100644
+--- a/src/linux.c
++++ b/src/linux.c
+@@ -847,12 +847,13 @@ ssize_t
+ __attribute__((__visibility__ ("hidden")))
+ make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
+ {
+- struct ifreq ifr = { 0, };
++ struct ifreq ifr;
+ struct ethtool_drvinfo drvinfo = { 0, };
+ int fd, rc;
+ ssize_t ret = -1, sz, off=0;
+ char busname[PATH_MAX+1] = "";
+
++ memset(&ifr, 0, sizeof (ifr));
+ strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
+ drvinfo.cmd = ETHTOOL_GDRVINFO;
+ ifr.ifr_data = (caddr_t)&drvinfo;
+--
+2.6.1
+
diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
index b5ef90a..1684a10 100644
--- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
+++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
@@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
DEPENDS_class-target = "popt efivar-native"
SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
-SRC_URI = "git://github.com/rhinstaller/efivar.git"
+SRC_URI = "git://github.com/rhinstaller/efivar.git \
+ file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
--
2.6.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [meta-oe][PATCH] efivar: fix zero initializer compiler error
2016-01-19 10:45 [meta-oe][PATCH] efivar: fix zero initializer compiler error Alexandru But
@ 2016-01-29 18:01 ` Martin Jansa
2016-02-01 9:24 ` Alexandru But
0 siblings, 1 reply; 8+ messages in thread
From: Martin Jansa @ 2016-01-29 18:01 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 4563 bytes --]
On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> Patch based on commit a3606c0:
> Sometimes the compiler doesn't like { 0,} as an initializer
Probably not caused by this change, but efivar now fails to build in
world build for qemuarm:
| linux.c: In function 'eb_nvme_ns_id':
| linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this function)
| uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
| ^
| linux.c:48:27: note: each undeclared identifier is reported only once for each function it appears in
| make[1]: *** [linux.o] Error 1
| make[1]: Leaving directory `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
| make: *** [src] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
NOTE: recipe efivar-0.21-r0: task do_compile: Failed
ERROR: Task 5672 (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/efivar_0.21.bb, do_compile) failed with exit code '1'
>
> Signed-off-by: Alexandru But <alexandru.but@ni.com>
> ---
> ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
> meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> 2 files changed, 44 insertions(+), 1 deletion(-)
> create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
>
> diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> new file mode 100644
> index 0000000..68cabd6
> --- /dev/null
> +++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> @@ -0,0 +1,42 @@
> +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
> +From: Peter Jones <pjones@redhat.com>
> +Date: Tue, 14 Jul 2015 09:33:54 -0400
> +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> + initializer...
> +
> +Because it really wants to be { {0, },} or something, and sometimes the
> +compiler, knowing full well what we're trying to do, likes to complain
> +about the rigor applied to our technique in doing it.
> +
> +memset() the struct ifreq to 0 instead so I don't need to figure out its
> +internal structure just to zero it out.
> +
> +Resolves #28
> +
> +Signed-off-by: Peter Jones <pjones@redhat.com>
> +---
> + src/linux.c | 3 ++-
> + 1 file changed, 2 insertions(+), 1 deletion(-)
> +
> +diff --git a/src/linux.c b/src/linux.c
> +index 57f71f3..817b8e6 100644
> +--- a/src/linux.c
> ++++ b/src/linux.c
> +@@ -847,12 +847,13 @@ ssize_t
> + __attribute__((__visibility__ ("hidden")))
> + make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
> + {
> +- struct ifreq ifr = { 0, };
> ++ struct ifreq ifr;
> + struct ethtool_drvinfo drvinfo = { 0, };
> + int fd, rc;
> + ssize_t ret = -1, sz, off=0;
> + char busname[PATH_MAX+1] = "";
> +
> ++ memset(&ifr, 0, sizeof (ifr));
> + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> + drvinfo.cmd = ETHTOOL_GDRVINFO;
> + ifr.ifr_data = (caddr_t)&drvinfo;
> +--
> +2.6.1
> +
> diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> index b5ef90a..1684a10 100644
> --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> DEPENDS_class-target = "popt efivar-native"
>
> SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> + file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
> SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
>
> --
> 2.6.1
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-oe][PATCH] efivar: fix zero initializer compiler error
2016-01-29 18:01 ` Martin Jansa
@ 2016-02-01 9:24 ` Alexandru But
2016-02-01 10:45 ` linux-yocto issues Was: " Martin Jansa
2016-02-01 18:46 ` Khem Raj
0 siblings, 2 replies; 8+ messages in thread
From: Alexandru But @ 2016-02-01 9:24 UTC (permalink / raw)
To: openembedded-devel
On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
> On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> > Patch based on commit a3606c0:
> > Sometimes the compiler doesn't like { 0,} as an initializer
>
> Probably not caused by this change, but efivar now fails to build in
> world build for qemuarm:
>
> | linux.c: In function 'eb_nvme_ns_id':
> | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this function)
> | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
> | ^
> | linux.c:48:27: note: each undeclared identifier is reported only once for each function it appears in
> | make[1]: *** [linux.o] Error 1
> | make[1]: Leaving directory `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
> | make: *** [src] Error 2
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
> NOTE: recipe efivar-0.21-r0: task do_compile: Failed
> ERROR: Task 5672 (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/efivar_0.21.bb, do_compile) failed with exit code '1'
>
Yes, I saw the error, and indeed is not related to this change. The problem is
that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is the
change:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
The Kconfig update unfortunately hasn't been change in the same time. It was
commited to the kernel only recently and will most likely be present in 4.5.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
In the standard/base repository that yocto uses, only the first of the above
changes have been pulled. The old header has a new name, so the desired macro
is no longer there. The problem could be solved from the utility point of view
with a patch that gentoo tree already has:
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
The problem is that even with this change the new header will not be found since
the second change is not yet in the yocto repo. I cherry-picked and created all
the changes above, but efivar still does not find the new header.
Problem is that the headers from sysroot are built by linux-libc-headers and
this recipe uses the static 4.4 linux release archive from kernel.org. If all
the above are pulled in and linux-libc-headers are using sources with both
changes, than efivar build will pass.
From my point of view the possible solutions for this problem are:
- Push the efivar patch and blacklist the recipe until linux-libc-headers points
to 4.5
- Revert the rename change in the yocto kernel repo and apply the efivar patch
after 4.5 token
- Apply the efivar patch, and a patch for linux-libc-headers
- Escalate the problem to the kernel comunity to backport the Kconfig change to
4.4
I am not sure which is the right approach since they all have downsides.
Regards,
Alex But
> >
> > Signed-off-by: Alexandru But <alexandru.but@ni.com>
> > ---
> > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
> > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> > 2 files changed, 44 insertions(+), 1 deletion(-)
> > create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> >
> > diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > new file mode 100644
> > index 0000000..68cabd6
> > --- /dev/null
> > +++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > @@ -0,0 +1,42 @@
> > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
> > +From: Peter Jones <pjones@redhat.com>
> > +Date: Tue, 14 Jul 2015 09:33:54 -0400
> > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> > + initializer...
> > +
> > +Because it really wants to be { {0, },} or something, and sometimes the
> > +compiler, knowing full well what we're trying to do, likes to complain
> > +about the rigor applied to our technique in doing it.
> > +
> > +memset() the struct ifreq to 0 instead so I don't need to figure out its
> > +internal structure just to zero it out.
> > +
> > +Resolves #28
> > +
> > +Signed-off-by: Peter Jones <pjones@redhat.com>
> > +---
> > + src/linux.c | 3 ++-
> > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/src/linux.c b/src/linux.c
> > +index 57f71f3..817b8e6 100644
> > +--- a/src/linux.c
> > ++++ b/src/linux.c
> > +@@ -847,12 +847,13 @@ ssize_t
> > + __attribute__((__visibility__ ("hidden")))
> > + make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
> > + {
> > +- struct ifreq ifr = { 0, };
> > ++ struct ifreq ifr;
> > + struct ethtool_drvinfo drvinfo = { 0, };
> > + int fd, rc;
> > + ssize_t ret = -1, sz, off=0;
> > + char busname[PATH_MAX+1] = "";
> > +
> > ++ memset(&ifr, 0, sizeof (ifr));
> > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> > + drvinfo.cmd = ETHTOOL_GDRVINFO;
> > + ifr.ifr_data = (caddr_t)&drvinfo;
> > +--
> > +2.6.1
> > +
> > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > index b5ef90a..1684a10 100644
> > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> > DEPENDS_class-target = "popt efivar-native"
> >
> > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> > + file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> > SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
> > SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
> >
> > --
> > 2.6.1
> >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* linux-yocto issues Was: [oe] [meta-oe][PATCH] efivar: fix zero initializer compiler error
2016-02-01 9:24 ` Alexandru But
@ 2016-02-01 10:45 ` Martin Jansa
2016-02-01 18:46 ` Khem Raj
1 sibling, 0 replies; 8+ messages in thread
From: Martin Jansa @ 2016-02-01 10:45 UTC (permalink / raw)
To: openembedded-devel; +Cc: Bruce Ashfield, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 7872 bytes --]
On Mon, Feb 01, 2016 at 11:24:03AM +0200, Alexandru But wrote:
> On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
> > On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> > > Patch based on commit a3606c0:
> > > Sometimes the compiler doesn't like { 0,} as an initializer
> >
> > Probably not caused by this change, but efivar now fails to build in
> > world build for qemuarm:
> >
> > | linux.c: In function 'eb_nvme_ns_id':
> > | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this function)
> > | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
> > | ^
> > | linux.c:48:27: note: each undeclared identifier is reported only once for each function it appears in
> > | make[1]: *** [linux.o] Error 1
> > | make[1]: Leaving directory `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
> > | make: *** [src] Error 2
> > | ERROR: oe_runmake failed
> > | ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
> > NOTE: recipe efivar-0.21-r0: task do_compile: Failed
> > ERROR: Task 5672 (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/efivar_0.21.bb, do_compile) failed with exit code '1'
> >
>
> Yes, I saw the error, and indeed is not related to this change. The problem is
> that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is the
> change:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
>
> The Kconfig update unfortunately hasn't been change in the same time. It was
> commited to the kernel only recently and will most likely be present in 4.5.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
>
> In the standard/base repository that yocto uses, only the first of the above
> changes have been pulled. The old header has a new name, so the desired macro
> is no longer there. The problem could be solved from the utility point of view
> with a patch that gentoo tree already has:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
>
> The problem is that even with this change the new header will not be found since
> the second change is not yet in the yocto repo. I cherry-picked and created all
> the changes above, but efivar still does not find the new header.
> Problem is that the headers from sysroot are built by linux-libc-headers and
> this recipe uses the static 4.4 linux release archive from kernel.org. If all
> the above are pulled in and linux-libc-headers are using sources with both
> changes, than efivar build will pass.
>
> From my point of view the possible solutions for this problem are:
> - Push the efivar patch and blacklist the recipe until linux-libc-headers points
> to 4.5
> - Revert the rename change in the yocto kernel repo and apply the efivar patch
> after 4.5 token
> - Apply the efivar patch, and a patch for linux-libc-headers
> - Escalate the problem to the kernel comunity to backport the Kconfig change to
> 4.4
>
> I am not sure which is the right approach since they all have downsides.
Thanks for detailed analysis, I don't use efivar or linux-yocto, so I
was reporting the issue only because I wasn't able to even build-test
your change in jenkins.
Adding oe-core and Bruce, because the issue is in
linux-yocto/linux-libc-headers maintained there.
Regards,
> > > Signed-off-by: Alexandru But <alexandru.but@ni.com>
> > > ---
> > > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
> > > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > >
> > > diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > new file mode 100644
> > > index 0000000..68cabd6
> > > --- /dev/null
> > > +++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > @@ -0,0 +1,42 @@
> > > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
> > > +From: Peter Jones <pjones@redhat.com>
> > > +Date: Tue, 14 Jul 2015 09:33:54 -0400
> > > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> > > + initializer...
> > > +
> > > +Because it really wants to be { {0, },} or something, and sometimes the
> > > +compiler, knowing full well what we're trying to do, likes to complain
> > > +about the rigor applied to our technique in doing it.
> > > +
> > > +memset() the struct ifreq to 0 instead so I don't need to figure out its
> > > +internal structure just to zero it out.
> > > +
> > > +Resolves #28
> > > +
> > > +Signed-off-by: Peter Jones <pjones@redhat.com>
> > > +---
> > > + src/linux.c | 3 ++-
> > > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > > +
> > > +diff --git a/src/linux.c b/src/linux.c
> > > +index 57f71f3..817b8e6 100644
> > > +--- a/src/linux.c
> > > ++++ b/src/linux.c
> > > +@@ -847,12 +847,13 @@ ssize_t
> > > + __attribute__((__visibility__ ("hidden")))
> > > + make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
> > > + {
> > > +- struct ifreq ifr = { 0, };
> > > ++ struct ifreq ifr;
> > > + struct ethtool_drvinfo drvinfo = { 0, };
> > > + int fd, rc;
> > > + ssize_t ret = -1, sz, off=0;
> > > + char busname[PATH_MAX+1] = "";
> > > +
> > > ++ memset(&ifr, 0, sizeof (ifr));
> > > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> > > + drvinfo.cmd = ETHTOOL_GDRVINFO;
> > > + ifr.ifr_data = (caddr_t)&drvinfo;
> > > +--
> > > +2.6.1
> > > +
> > > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > index b5ef90a..1684a10 100644
> > > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> > > DEPENDS_class-target = "popt efivar-native"
> > >
> > > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> > > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> > > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> > > + file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> > > SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
> > > SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
> > >
> > > --
> > > 2.6.1
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> > --
> > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
>
>
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* linux-yocto issues Was: [meta-oe][PATCH] efivar: fix zero initializer compiler error
@ 2016-02-01 10:45 ` Martin Jansa
0 siblings, 0 replies; 8+ messages in thread
From: Martin Jansa @ 2016-02-01 10:45 UTC (permalink / raw)
To: openembedded-devel; +Cc: Bruce Ashfield, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 7872 bytes --]
On Mon, Feb 01, 2016 at 11:24:03AM +0200, Alexandru But wrote:
> On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
> > On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> > > Patch based on commit a3606c0:
> > > Sometimes the compiler doesn't like { 0,} as an initializer
> >
> > Probably not caused by this change, but efivar now fails to build in
> > world build for qemuarm:
> >
> > | linux.c: In function 'eb_nvme_ns_id':
> > | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this function)
> > | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
> > | ^
> > | linux.c:48:27: note: each undeclared identifier is reported only once for each function it appears in
> > | make[1]: *** [linux.o] Error 1
> > | make[1]: Leaving directory `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
> > | make: *** [src] Error 2
> > | ERROR: oe_runmake failed
> > | ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
> > NOTE: recipe efivar-0.21-r0: task do_compile: Failed
> > ERROR: Task 5672 (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/efivar_0.21.bb, do_compile) failed with exit code '1'
> >
>
> Yes, I saw the error, and indeed is not related to this change. The problem is
> that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is the
> change:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
>
> The Kconfig update unfortunately hasn't been change in the same time. It was
> commited to the kernel only recently and will most likely be present in 4.5.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
>
> In the standard/base repository that yocto uses, only the first of the above
> changes have been pulled. The old header has a new name, so the desired macro
> is no longer there. The problem could be solved from the utility point of view
> with a patch that gentoo tree already has:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
>
> The problem is that even with this change the new header will not be found since
> the second change is not yet in the yocto repo. I cherry-picked and created all
> the changes above, but efivar still does not find the new header.
> Problem is that the headers from sysroot are built by linux-libc-headers and
> this recipe uses the static 4.4 linux release archive from kernel.org. If all
> the above are pulled in and linux-libc-headers are using sources with both
> changes, than efivar build will pass.
>
> From my point of view the possible solutions for this problem are:
> - Push the efivar patch and blacklist the recipe until linux-libc-headers points
> to 4.5
> - Revert the rename change in the yocto kernel repo and apply the efivar patch
> after 4.5 token
> - Apply the efivar patch, and a patch for linux-libc-headers
> - Escalate the problem to the kernel comunity to backport the Kconfig change to
> 4.4
>
> I am not sure which is the right approach since they all have downsides.
Thanks for detailed analysis, I don't use efivar or linux-yocto, so I
was reporting the issue only because I wasn't able to even build-test
your change in jenkins.
Adding oe-core and Bruce, because the issue is in
linux-yocto/linux-libc-headers maintained there.
Regards,
> > > Signed-off-by: Alexandru But <alexandru.but@ni.com>
> > > ---
> > > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
> > > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > >
> > > diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > new file mode 100644
> > > index 0000000..68cabd6
> > > --- /dev/null
> > > +++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > @@ -0,0 +1,42 @@
> > > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
> > > +From: Peter Jones <pjones@redhat.com>
> > > +Date: Tue, 14 Jul 2015 09:33:54 -0400
> > > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> > > + initializer...
> > > +
> > > +Because it really wants to be { {0, },} or something, and sometimes the
> > > +compiler, knowing full well what we're trying to do, likes to complain
> > > +about the rigor applied to our technique in doing it.
> > > +
> > > +memset() the struct ifreq to 0 instead so I don't need to figure out its
> > > +internal structure just to zero it out.
> > > +
> > > +Resolves #28
> > > +
> > > +Signed-off-by: Peter Jones <pjones@redhat.com>
> > > +---
> > > + src/linux.c | 3 ++-
> > > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > > +
> > > +diff --git a/src/linux.c b/src/linux.c
> > > +index 57f71f3..817b8e6 100644
> > > +--- a/src/linux.c
> > > ++++ b/src/linux.c
> > > +@@ -847,12 +847,13 @@ ssize_t
> > > + __attribute__((__visibility__ ("hidden")))
> > > + make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
> > > + {
> > > +- struct ifreq ifr = { 0, };
> > > ++ struct ifreq ifr;
> > > + struct ethtool_drvinfo drvinfo = { 0, };
> > > + int fd, rc;
> > > + ssize_t ret = -1, sz, off=0;
> > > + char busname[PATH_MAX+1] = "";
> > > +
> > > ++ memset(&ifr, 0, sizeof (ifr));
> > > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> > > + drvinfo.cmd = ETHTOOL_GDRVINFO;
> > > + ifr.ifr_data = (caddr_t)&drvinfo;
> > > +--
> > > +2.6.1
> > > +
> > > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > index b5ef90a..1684a10 100644
> > > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> > > DEPENDS_class-target = "popt efivar-native"
> > >
> > > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> > > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> > > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> > > + file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> > > SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
> > > SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
> > >
> > > --
> > > 2.6.1
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> > --
> > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
>
>
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: linux-yocto issues Was: [oe] [meta-oe][PATCH] efivar: fix zero initializer compiler error
2016-02-01 10:45 ` linux-yocto issues Was: " Martin Jansa
@ 2016-02-01 13:33 ` Bruce Ashfield
-1 siblings, 0 replies; 8+ messages in thread
From: Bruce Ashfield @ 2016-02-01 13:33 UTC (permalink / raw)
To: Martin Jansa, alexandru.but; +Cc: openembedded-devel, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 9294 bytes --]
On Mon, Feb 1, 2016 at 5:45 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, Feb 01, 2016 at 11:24:03AM +0200, Alexandru But wrote:
> > On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
> > > On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> > > > Patch based on commit a3606c0:
> > > > Sometimes the compiler doesn't like { 0,} as an initializer
> > >
> > > Probably not caused by this change, but efivar now fails to build in
> > > world build for qemuarm:
> > >
> > > | linux.c: In function 'eb_nvme_ns_id':
> > > | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this
> function)
> > > | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
> > > | ^
> > > | linux.c:48:27: note: each undeclared identifier is reported only
> once for each function it appears in
> > > | make[1]: *** [linux.o] Error 1
> > > | make[1]: Leaving directory
> `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
> > > | make: *** [src] Error 2
> > > | ERROR: oe_runmake failed
> > > | ERROR: Function failed: do_compile (log file is located at
> /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
> > > NOTE: recipe efivar-0.21-r0: task do_compile: Failed
> > > ERROR: Task 5672
> (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/
> efivar_0.21.bb, do_compile) failed with exit code '1'
> > >
> >
> > Yes, I saw the error, and indeed is not related to this change. The
> problem is
> > that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is
> the
> > change:
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
> >
> > The Kconfig update unfortunately hasn't been change in the same time. It
> was
> > commited to the kernel only recently and will most likely be present in
> 4.5.
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
> >
> > In the standard/base repository that yocto uses, only the first of the
> above
> > changes have been pulled. The old header has a new name, so the desired
> macro
> > is no longer there. The problem could be solved from the utility point
> of view
> > with a patch that gentoo tree already has:
> >
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
> >
> > The problem is that even with this change the new header will not be
> found since
> > the second change is not yet in the yocto repo. I cherry-picked and
> created all
> > the changes above, but efivar still does not find the new header.
> > Problem is that the headers from sysroot are built by linux-libc-headers
> and
> > this recipe uses the static 4.4 linux release archive from kernel.org.
> If all
> > the above are pulled in and linux-libc-headers are using sources with
> both
> > changes, than efivar build will pass.
> >
> > From my point of view the possible solutions for this problem are:
> > - Push the efivar patch and blacklist the recipe until
> linux-libc-headers points
> > to 4.5
> > - Revert the rename change in the yocto kernel repo and apply the efivar
> patch
> > after 4.5 token
> > - Apply the efivar patch, and a patch for linux-libc-headers
> > - Escalate the problem to the kernel comunity to backport the Kconfig
> change to
> > 4.4
> >
> > I am not sure which is the right approach since they all have downsides.
>
> Thanks for detailed analysis, I don't use efivar or linux-yocto, so I
> was reporting the issue only because I wasn't able to even build-test
> your change in jenkins.
>
> Adding oe-core and Bruce, because the issue is in
> linux-yocto/linux-libc-headers maintained there.
>
>
Thanks Martin and Alexandru,
Alexandru: since we'd like to fix this everywhere, and not just someone
building,
against linux-yocto .. and I'd rather not wait until the 4.5 kernel is
released (so
I can bump the libc-headers).
I'd suggest that we patch linux-libc-headers to have the proper
definitions, can
you prepare a patch, since you are currently building efivar and can
quickly confim
a fix ?
We can also nominate the Kconfig change to be backported to 4.4, but we can
get things working in the mean time.
Cheers,
Bruce
> Regards,
>
> > > > Signed-off-by: Alexandru But <alexandru.but@ni.com>
> > > > ---
> > > > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42
> ++++++++++++++++++++++
> > > > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> > > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > > create mode 100644
> meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > >
> > > > diff --git
> a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > > new file mode 100644
> > > > index 0000000..68cabd6
> > > > --- /dev/null
> > > > +++
> b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > > @@ -0,0 +1,42 @@
> > > > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00
> 2001
> > > > +From: Peter Jones <pjones@redhat.com>
> > > > +Date: Tue, 14 Jul 2015 09:33:54 -0400
> > > > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> > > > + initializer...
> > > > +
> > > > +Because it really wants to be { {0, },} or something, and sometimes
> the
> > > > +compiler, knowing full well what we're trying to do, likes to
> complain
> > > > +about the rigor applied to our technique in doing it.
> > > > +
> > > > +memset() the struct ifreq to 0 instead so I don't need to figure
> out its
> > > > +internal structure just to zero it out.
> > > > +
> > > > +Resolves #28
> > > > +
> > > > +Signed-off-by: Peter Jones <pjones@redhat.com>
> > > > +---
> > > > + src/linux.c | 3 ++-
> > > > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > +
> > > > +diff --git a/src/linux.c b/src/linux.c
> > > > +index 57f71f3..817b8e6 100644
> > > > +--- a/src/linux.c
> > > > ++++ b/src/linux.c
> > > > +@@ -847,12 +847,13 @@ ssize_t
> > > > + __attribute__((__visibility__ ("hidden")))
> > > > + make_mac_path(uint8_t *buf, ssize_t size, const char * const
> ifname)
> > > > + {
> > > > +- struct ifreq ifr = { 0, };
> > > > ++ struct ifreq ifr;
> > > > + struct ethtool_drvinfo drvinfo = { 0, };
> > > > + int fd, rc;
> > > > + ssize_t ret = -1, sz, off=0;
> > > > + char busname[PATH_MAX+1] = "";
> > > > +
> > > > ++ memset(&ifr, 0, sizeof (ifr));
> > > > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> > > > + drvinfo.cmd = ETHTOOL_GDRVINFO;
> > > > + ifr.ifr_data = (caddr_t)&drvinfo;
> > > > +--
> > > > +2.6.1
> > > > +
> > > > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > index b5ef90a..1684a10 100644
> > > > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> > > > DEPENDS_class-target = "popt efivar-native"
> > > >
> > > > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> > > > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> > > > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> > > > +
> file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> > > > SRC_URI_append_class-target = "
> file://0001-efivar-fix-for-cross-compile.patch"
> > > > SRC_URI_append_class-native = "
> file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
> > > >
> > > > --
> > > > 2.6.1
> > > >
> > > > --
> > > > _______________________________________________
> > > > Openembedded-devel mailing list
> > > > Openembedded-devel@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
> > > --
> > > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
> >
> >
> >
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
[-- Attachment #2: Type: text/html, Size: 15115 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [OE-core] linux-yocto issues Was: [meta-oe][PATCH] efivar: fix zero initializer compiler error
@ 2016-02-01 13:33 ` Bruce Ashfield
0 siblings, 0 replies; 8+ messages in thread
From: Bruce Ashfield @ 2016-02-01 13:33 UTC (permalink / raw)
To: Martin Jansa, alexandru.but; +Cc: openembedded-devel, openembedded-core
On Mon, Feb 1, 2016 at 5:45 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, Feb 01, 2016 at 11:24:03AM +0200, Alexandru But wrote:
> > On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
> > > On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
> > > > Patch based on commit a3606c0:
> > > > Sometimes the compiler doesn't like { 0,} as an initializer
> > >
> > > Probably not caused by this change, but efivar now fails to build in
> > > world build for qemuarm:
> > >
> > > | linux.c: In function 'eb_nvme_ns_id':
> > > | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this
> function)
> > > | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
> > > | ^
> > > | linux.c:48:27: note: each undeclared identifier is reported only
> once for each function it appears in
> > > | make[1]: *** [linux.o] Error 1
> > > | make[1]: Leaving directory
> `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
> > > | make: *** [src] Error 2
> > > | ERROR: oe_runmake failed
> > > | ERROR: Function failed: do_compile (log file is located at
> /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
> > > NOTE: recipe efivar-0.21-r0: task do_compile: Failed
> > > ERROR: Task 5672
> (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/
> efivar_0.21.bb, do_compile) failed with exit code '1'
> > >
> >
> > Yes, I saw the error, and indeed is not related to this change. The
> problem is
> > that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is
> the
> > change:
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
> >
> > The Kconfig update unfortunately hasn't been change in the same time. It
> was
> > commited to the kernel only recently and will most likely be present in
> 4.5.
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
> >
> > In the standard/base repository that yocto uses, only the first of the
> above
> > changes have been pulled. The old header has a new name, so the desired
> macro
> > is no longer there. The problem could be solved from the utility point
> of view
> > with a patch that gentoo tree already has:
> >
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
> >
> > The problem is that even with this change the new header will not be
> found since
> > the second change is not yet in the yocto repo. I cherry-picked and
> created all
> > the changes above, but efivar still does not find the new header.
> > Problem is that the headers from sysroot are built by linux-libc-headers
> and
> > this recipe uses the static 4.4 linux release archive from kernel.org.
> If all
> > the above are pulled in and linux-libc-headers are using sources with
> both
> > changes, than efivar build will pass.
> >
> > From my point of view the possible solutions for this problem are:
> > - Push the efivar patch and blacklist the recipe until
> linux-libc-headers points
> > to 4.5
> > - Revert the rename change in the yocto kernel repo and apply the efivar
> patch
> > after 4.5 token
> > - Apply the efivar patch, and a patch for linux-libc-headers
> > - Escalate the problem to the kernel comunity to backport the Kconfig
> change to
> > 4.4
> >
> > I am not sure which is the right approach since they all have downsides.
>
> Thanks for detailed analysis, I don't use efivar or linux-yocto, so I
> was reporting the issue only because I wasn't able to even build-test
> your change in jenkins.
>
> Adding oe-core and Bruce, because the issue is in
> linux-yocto/linux-libc-headers maintained there.
>
>
Thanks Martin and Alexandru,
Alexandru: since we'd like to fix this everywhere, and not just someone
building,
against linux-yocto .. and I'd rather not wait until the 4.5 kernel is
released (so
I can bump the libc-headers).
I'd suggest that we patch linux-libc-headers to have the proper
definitions, can
you prepare a patch, since you are currently building efivar and can
quickly confim
a fix ?
We can also nominate the Kconfig change to be backported to 4.4, but we can
get things working in the mean time.
Cheers,
Bruce
> Regards,
>
> > > > Signed-off-by: Alexandru But <alexandru.but@ni.com>
> > > > ---
> > > > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42
> ++++++++++++++++++++++
> > > > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
> > > > 2 files changed, 44 insertions(+), 1 deletion(-)
> > > > create mode 100644
> meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > >
> > > > diff --git
> a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > > new file mode 100644
> > > > index 0000000..68cabd6
> > > > --- /dev/null
> > > > +++
> b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
> > > > @@ -0,0 +1,42 @@
> > > > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00
> 2001
> > > > +From: Peter Jones <pjones@redhat.com>
> > > > +Date: Tue, 14 Jul 2015 09:33:54 -0400
> > > > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
> > > > + initializer...
> > > > +
> > > > +Because it really wants to be { {0, },} or something, and sometimes
> the
> > > > +compiler, knowing full well what we're trying to do, likes to
> complain
> > > > +about the rigor applied to our technique in doing it.
> > > > +
> > > > +memset() the struct ifreq to 0 instead so I don't need to figure
> out its
> > > > +internal structure just to zero it out.
> > > > +
> > > > +Resolves #28
> > > > +
> > > > +Signed-off-by: Peter Jones <pjones@redhat.com>
> > > > +---
> > > > + src/linux.c | 3 ++-
> > > > + 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > +
> > > > +diff --git a/src/linux.c b/src/linux.c
> > > > +index 57f71f3..817b8e6 100644
> > > > +--- a/src/linux.c
> > > > ++++ b/src/linux.c
> > > > +@@ -847,12 +847,13 @@ ssize_t
> > > > + __attribute__((__visibility__ ("hidden")))
> > > > + make_mac_path(uint8_t *buf, ssize_t size, const char * const
> ifname)
> > > > + {
> > > > +- struct ifreq ifr = { 0, };
> > > > ++ struct ifreq ifr;
> > > > + struct ethtool_drvinfo drvinfo = { 0, };
> > > > + int fd, rc;
> > > > + ssize_t ret = -1, sz, off=0;
> > > > + char busname[PATH_MAX+1] = "";
> > > > +
> > > > ++ memset(&ifr, 0, sizeof (ifr));
> > > > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
> > > > + drvinfo.cmd = ETHTOOL_GDRVINFO;
> > > > + ifr.ifr_data = (caddr_t)&drvinfo;
> > > > +--
> > > > +2.6.1
> > > > +
> > > > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > index b5ef90a..1684a10 100644
> > > > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
> > > > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
> > > > DEPENDS_class-target = "popt efivar-native"
> > > >
> > > > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
> > > > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
> > > > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
> > > > +
> file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
> > > > SRC_URI_append_class-target = "
> file://0001-efivar-fix-for-cross-compile.patch"
> > > > SRC_URI_append_class-native = "
> file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
> > > >
> > > > --
> > > > 2.6.1
> > > >
> > > > --
> > > > _______________________________________________
> > > > Openembedded-devel mailing list
> > > > Openembedded-devel@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> > >
> > > --
> > > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
> >
> >
> >
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
> > --
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [meta-oe][PATCH] efivar: fix zero initializer compiler error
2016-02-01 9:24 ` Alexandru But
2016-02-01 10:45 ` linux-yocto issues Was: " Martin Jansa
@ 2016-02-01 18:46 ` Khem Raj
1 sibling, 0 replies; 8+ messages in thread
From: Khem Raj @ 2016-02-01 18:46 UTC (permalink / raw)
To: openembeded-devel
On Mon, Feb 1, 2016 at 1:24 AM, Alexandru But <alexandru.but@ni.com> wrote:
> On Fri, Jan 29, 2016 at 07:01:57PM +0100, Martin Jansa wrote:
>> On Tue, Jan 19, 2016 at 12:45:18PM +0200, Alexandru But wrote:
>> > Patch based on commit a3606c0:
>> > Sometimes the compiler doesn't like { 0,} as an initializer
>>
>> Probably not caused by this change, but efivar now fails to build in
>> world build for qemuarm:
>>
>> | linux.c: In function 'eb_nvme_ns_id':
>> | linux.c:48:27: error: 'NVME_IOCTL_ID' undeclared (first use in this function)
>> | uint64_t ret = ioctl(fd, NVME_IOCTL_ID, NULL);
>> | ^
>> | linux.c:48:27: note: each undeclared identifier is reported only once for each function it appears in
>> | make[1]: *** [linux.o] Error 1
>> | make[1]: Leaving directory `/home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/git/src'
>> | make: *** [src] Error 2
>> | ERROR: oe_runmake failed
>> | ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/armv5te-oe-linux-gnueabi/efivar/0.21-r0/temp/log.do_compile.8376)
>> NOTE: recipe efivar-0.21-r0: task do_compile: Failed
>> ERROR: Task 5672 (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/efivar/efivar_0.21.bb, do_compile) failed with exit code '1'
>>
>
> Yes, I saw the error, and indeed is not related to this change. The problem is
> that NVMe uapi header was renamed from nvme.h to nvme_ioctl.h. Here is the
> change:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d99a8dda154f38307d43d9c9aa504bd3703d596
>
> The Kconfig update unfortunately hasn't been change in the same time. It was
> commited to the kernel only recently and will most likely be present in 4.5.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a9cf8284b45110a4d98aea180a89c857e53bf850
>
> In the standard/base repository that yocto uses, only the first of the above
> changes have been pulled. The old header has a new name, so the desired macro
> is no longer there. The problem could be solved from the utility point of view
> with a patch that gentoo tree already has:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/efivar/files/0.21-nvme_ioctl.h.patch
>
> The problem is that even with this change the new header will not be found since
> the second change is not yet in the yocto repo. I cherry-picked and created all
> the changes above, but efivar still does not find the new header.
> Problem is that the headers from sysroot are built by linux-libc-headers and
> this recipe uses the static 4.4 linux release archive from kernel.org. If all
> the above are pulled in and linux-libc-headers are using sources with both
> changes, than efivar build will pass.
>
> From my point of view the possible solutions for this problem are:
> - Push the efivar patch and blacklist the recipe until linux-libc-headers points
> to 4.5
this is usually not preferred since its far away, please propose a
backport to linux-yocto 4.4
> - Revert the rename change in the yocto kernel repo and apply the efivar patch
> after 4.5 token
> - Apply the efivar patch, and a patch for linux-libc-headers
> - Escalate the problem to the kernel comunity to backport the Kconfig change to
> 4.4
yes thats the right long term approach.
>
> I am not sure which is the right approach since they all have downsides.
>
> Regards,
> Alex But
>
>> >
>> > Signed-off-by: Alexandru But <alexandru.but@ni.com>
>> > ---
>> > ...he-compiler-doesn-t-like-0-as-an-initiali.patch | 42 ++++++++++++++++++++++
>> > meta-oe/recipes-extended/efivar/efivar_0.21.bb | 3 +-
>> > 2 files changed, 44 insertions(+), 1 deletion(-)
>> > create mode 100644 meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
>> >
>> > diff --git a/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
>> > new file mode 100644
>> > index 0000000..68cabd6
>> > --- /dev/null
>> > +++ b/meta-oe/recipes-extended/efivar/efivar/0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch
>> > @@ -0,0 +1,42 @@
>> > +From a3606c02fd271d32e364fcc540e34ba1899309f6 Mon Sep 17 00:00:00 2001
>> > +From: Peter Jones <pjones@redhat.com>
>> > +Date: Tue, 14 Jul 2015 09:33:54 -0400
>> > +Subject: [PATCH] Sometimes the compiler doesn't like { 0, } as an
>> > + initializer...
>> > +
>> > +Because it really wants to be { {0, },} or something, and sometimes the
>> > +compiler, knowing full well what we're trying to do, likes to complain
>> > +about the rigor applied to our technique in doing it.
>> > +
>> > +memset() the struct ifreq to 0 instead so I don't need to figure out its
>> > +internal structure just to zero it out.
>> > +
>> > +Resolves #28
>> > +
>> > +Signed-off-by: Peter Jones <pjones@redhat.com>
>> > +---
>> > + src/linux.c | 3 ++-
>> > + 1 file changed, 2 insertions(+), 1 deletion(-)
>> > +
>> > +diff --git a/src/linux.c b/src/linux.c
>> > +index 57f71f3..817b8e6 100644
>> > +--- a/src/linux.c
>> > ++++ b/src/linux.c
>> > +@@ -847,12 +847,13 @@ ssize_t
>> > + __attribute__((__visibility__ ("hidden")))
>> > + make_mac_path(uint8_t *buf, ssize_t size, const char * const ifname)
>> > + {
>> > +- struct ifreq ifr = { 0, };
>> > ++ struct ifreq ifr;
>> > + struct ethtool_drvinfo drvinfo = { 0, };
>> > + int fd, rc;
>> > + ssize_t ret = -1, sz, off=0;
>> > + char busname[PATH_MAX+1] = "";
>> > +
>> > ++ memset(&ifr, 0, sizeof (ifr));
>> > + strncpy(ifr.ifr_name, ifname, IF_NAMESIZE);
>> > + drvinfo.cmd = ETHTOOL_GDRVINFO;
>> > + ifr.ifr_data = (caddr_t)&drvinfo;
>> > +--
>> > +2.6.1
>> > +
>> > diff --git a/meta-oe/recipes-extended/efivar/efivar_0.21.bb b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
>> > index b5ef90a..1684a10 100644
>> > --- a/meta-oe/recipes-extended/efivar/efivar_0.21.bb
>> > +++ b/meta-oe/recipes-extended/efivar/efivar_0.21.bb
>> > @@ -8,7 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
>> > DEPENDS_class-target = "popt efivar-native"
>> >
>> > SRCREV = "aab6c2a64d90b6e5a63661fb5bd6be8d878b0784"
>> > -SRC_URI = "git://github.com/rhinstaller/efivar.git"
>> > +SRC_URI = "git://github.com/rhinstaller/efivar.git \
>> > + file://0001-Sometimes-the-compiler-doesn-t-like-0-as-an-initiali.patch"
>> > SRC_URI_append_class-target = " file://0001-efivar-fix-for-cross-compile.patch"
>> > SRC_URI_append_class-native = " file://efivar-drop-options-not-supported-by-lower-version-gcc.patch"
>> >
>> > --
>> > 2.6.1
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-devel mailing list
>> > Openembedded-devel@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>> --
>> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
>
>
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-02-01 18:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-19 10:45 [meta-oe][PATCH] efivar: fix zero initializer compiler error Alexandru But
2016-01-29 18:01 ` Martin Jansa
2016-02-01 9:24 ` Alexandru But
2016-02-01 10:45 ` linux-yocto issues Was: [oe] " Martin Jansa
2016-02-01 10:45 ` linux-yocto issues Was: " Martin Jansa
2016-02-01 13:33 ` linux-yocto issues Was: [oe] " Bruce Ashfield
2016-02-01 13:33 ` [OE-core] linux-yocto issues Was: " Bruce Ashfield
2016-02-01 18:46 ` Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.