Date   

Re: SRC_URI Directory Change

Chuck Wolber
 



On Fri, Oct 15, 2021 at 6:58 AM Richard Purdie <richard.purdie@...> wrote:

I have a bit of a horrible idea to do this in master-next which does solve the
problem. We probably need a new bitbake selftest testcase before I could think
about merging it though.

I tested the patch you posted on IRC against bitbake 1.50.0. It seems to work
quite well, but I think I found two minor bugs in it. I pasted an updated patch below.

In a nutshell...

If you have a SRC_URI file:// entry that ends in a "/", then you get a "." that is
not enclosed in "/./" when running the checksum_dir method, which causes
checksum_file to throw warnings that look like this:

WARNING: Unable to get checksum for gettext-minimal-native SRC_URI entry .intlmacosx.m4: [Errno 2] No such file or directory: '/mnt/openembedded-core/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/.intlmacosx.m4'

I think the simplest fix is to add a "pth = pth.rstrip("/")" in the checksum_dir method after
the guard statement. But then that exposes a different issue in the patch.

For recipes that trigger the above warning, the rstrip() fix fixes the warning, but then you
expose a new problem in siggen.py calc_taskhash().

In your patched version, the check for the "/" fails to include the filename in the hash calculation
for files at the root of a SRC_URI entry (there is no "/" to be found). This results in a task hash
mismatch error on the first build, but not on subsequent builds for fairly obvious reasons.

I solved this by adding a third field to the tuple with a True/False value, which is a much more reliable semaphore (IMHO).

I tested these fixes and it worked perfectly. Here is an updated version of your patch that takes into
account the fixes I described. I can produce a "patch against your patch" if these fixes are
considered correct and do not cause even bigger problems that are not obvious to me.

diff --git a/bitbake/lib/bb/checksum.py b/bitbake/lib/bb/checksum.py
index 1d50a26426..fb8a77f6ab 100644
--- a/bitbake/lib/bb/checksum.py
+++ b/bitbake/lib/bb/checksum.py
@@ -50,6 +50,7 @@ class FileChecksumCache(MultiProcessCache):
         MultiProcessCache.__init__(self)
 
     def get_checksum(self, f):
+        f = os.path.normpath(f)
         entry = self.cachedata[0].get(f)
         cmtime = self.mtime_cache.cached_mtime(f)
         if entry:
@@ -84,15 +85,24 @@ class FileChecksumCache(MultiProcessCache):
                 return None
             return checksum
 
+        #
+        # Changing the format of file-checksums is problematic as both OE and Bitbake have
+        # knowledge of them. We need to encode a new piece of data, the portion of the path
+        # we care about from a checksum perspective. This means that files that change subdirectory
+        # are tracked by the task hashes. To do this, we do something horrible and put a "/./" into
+        # the path. The filesystem handles it but it gives us a marker to know which subsection
+        # of the path to cache.
+        #
         def checksum_dir(pth):
             # Handle directories recursively
             if pth == "/":
                 bb.fatal("Refusing to checksum /")
+            pth = pth.rstrip("/")
             dirchecksums = []
             for root, dirs, files in os.walk(pth, topdown=True):
                 [dirs.remove(d) for d in list(dirs) if d in localdirsexclude]
                 for name in files:
-                    fullpth = os.path.join(root, name)
+                    fullpth = os.path.join(root, name).replace(pth, os.path.join(pth, "."))
                     checksum = checksum_file(fullpth)
                     if checksum:
                         dirchecksums.append((fullpth, checksum))
diff --git a/bitbake/lib/bb/siggen.py b/bitbake/lib/bb/siggen.py
index 0d88c6ec68..f649f39ced 100644
--- a/bitbake/lib/bb/siggen.py
+++ b/bitbake/lib/bb/siggen.py
@@ -308,13 +308,14 @@ class SignatureGeneratorBasic(SignatureGenerator):
         return
 
     def get_taskhash(self, tid, deps, dataCaches):
-
         data = self.basehash[tid]
         for dep in self.runtaskdeps[tid]:
             data = data + self.get_unihash(dep)
 
         for (f, cs) in self.file_checksum_values[tid]:
             if cs:
+                if "/./" in f:
+                    data = data + f.split("/./")[1]
                 data = data + cs
 
         if tid in self.taints:
@@ -372,7 +373,12 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         if runtime and tid in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[tid]
-            data['file_checksum_values'] = [(os.path.basename(f), cs) for f,cs in self.file_checksum_values[tid]]
+            data['file_checksum_values'] = []
+            for f,cs in self.file_checksum_values[tid]:
+                if "/./" in f:
+                    data['file_checksum_values'].append((f.split("/./")[1], cs, True))
+                else:
+                    data['file_checksum_values'].append((os.path.basename(f), cs, False))
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
                 data['runtaskhashes'][dep] = self.get_unihash(dep)
@@ -1017,6 +1023,8 @@ def calc_taskhash(sigdata):
 
     for c in sigdata['file_checksum_values']:
         if c[1]:
+            if c[2]:
+                data = data + c[0]
             data = data + c[1]
 
     if 'taint' in sigdata:

..Ch:W..

P.S. The gettext-minimal-native_0.21.bb (from OEC) is a very good example of something that triggers this behavior. But I found plenty of others as well.
 
--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: How to enable graphics acceleration on qemux86-64?

Alexander Kanavin
 

On Sat, 16 Oct 2021 at 14:08, Manuel Wagesreither <ManWag@...> wrote:
Here are some updates:

Building core-image-weston on hardknott succeeded. Couldn't `runqmu kvm slirp sdl core-image-weston` first because I got an error message about 'dri.pc' being missing. Debian package search told me it's part of 'mesa-commond-dev', so I installed it on my host machine and indeed, that runqemu command above got working again. Not just that, now even OpenGL acceleration with `runqmu kvm slirp sdl gl core-image-weston` worked, altough I didn't change anything OpenGL-wise. core-image-weston feels really snappy now. Great!

I got curious and reverted back to dunfell to check if the now-installed dri.pc made a difference, but no, it didn't. `runqemu` with `sdl` started (like it did before), and with `sdl gl` it still said "OpenGL support is disabled".

You need to replicate the settings from oe-selftest (link provided previously). I think on dunfell it's not enabled out of the box, and needs to be configured explicitly.
 
Ok, so then I moved on to get my own image which is on hardknott now working.

I `runqemu`d my image with 'sdl' and 'gl' and it started up fine. Weston did no longer start automatically so I did manually. Ran `DISPLAY=:0 glxgears` but it told me "couldn't open display :0". Installed 'weston-xwayland' so I'd get "/usr/lib/libweston-9/xwayland.so" but that didn't change anything.

Can't yet say if `DISPLAY=:0 glxgears` works on core-image-weston as it's still building.

DISPLAY is a setting for the host, so qemu can display the sdl or gtk window. On the qemu guest you need to get weston to start first.

Alex


Re: How to enable graphics acceleration on qemux86-64?

Manuel Wagesreither
 

Am Mi, 13. Okt 2021, um 22:56, schrieb Alexander Kanavin:
If you switch to master, it's best if you make a new build directory and dont reuse the one you have.

Alex

On Wed, 13 Oct 2021 at 22:09, Manuel Wagesreither <ManWag@...> wrote:

`export DISPLAY=:0` did the trick.

The following shows when still on poky dunfell:

* I can now boot `runqmu kvm slirp sdl core-image-weston`. But gui is still slow. I cannot even type `systemctl poweroff` in weston-terminal, it inevitably becomes `wweesssttooo[...]`.
* `runqemu kvm slirp sdl gl core-image-weston` still fails with `Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled`.

Updated to current poky master, but got this: `ERROR: ParseError in configuration INHERITs: Could not inherit file classes/image-mklibs.bbclass`.

Switched to hardknott-3.3.3 which is four weeks old and perhaps a little riper. It's currently building.

Regards,
Manuel




Here are some updates:

Building core-image-weston on hardknott succeeded. Couldn't `runqmu kvm slirp sdl core-image-weston` first because I got an error message about 'dri.pc' being missing. Debian package search told me it's part of 'mesa-commond-dev', so I installed it on my host machine and indeed, that runqemu command above got working again. Not just that, now even OpenGL acceleration with `runqmu kvm slirp sdl gl core-image-weston` worked, altough I didn't change anything OpenGL-wise. core-image-weston feels really snappy now. Great!

I got curious and reverted back to dunfell to check if the now-installed dri.pc made a difference, but no, it didn't. `runqemu` with `sdl` started (like it did before), and with `sdl gl` it still said "OpenGL support is disabled".

Ok, so then I moved on to get my own image which is on hardknott now working.

I `runqemu`d my image with 'sdl' and 'gl' and it started up fine. Weston did no longer start automatically so I did manually. Ran `DISPLAY=:0 glxgears` but it told me "couldn't open display :0". Installed 'weston-xwayland' so I'd get "/usr/lib/libweston-9/xwayland.so" but that didn't change anything.

Can't yet say if `DISPLAY=:0 glxgears` works on core-image-weston as it's still building.

Regards, Manuel


Dunfell: problem with kernel-module install and libkmod.so

Patrick Boettcher
 

Hi list,

I'm facing an issue with a BSP I created using dunfell (up-to-date on
poky and oe). I'm using a stable kernel and u-boot 2021.07 from denx's
mainline-stable-layer.

I stripped down my machine.conf and basically the boot is working fine.
Was working fine.

When finally I created a functional defconfig (one which didn't strip
down the kernel next to nothing - thanks to KCONFIG_MODE="alldefconfig"
). I started to create fragments to remove unused parts.

The very first fragment I created was leading to rootfs which crashed
at the moment when /sbin/init was invoked, with the strangest errors
I've ever seen:

/sbin/init: error while loading shared libraries: libkmod.so.2:
cannot open shared object file: No such file or directory

Of course libkmod.so.2 (and its target) is present.

Then I realized that no modules where installed in the rootfs. (modules
are there if I don't have the fragment)

So I added kernel-modules to IMAGE_INSTALL:append .

The modules appeared, but the panic still occurred.

What can I do to understand what's going on? I diff'ed the rootfs, the
only difference I could was in ldconfig's aux-cache.

Thanks for any help in advance,
--
Patrick.


Re: SRC_URI Directory Change

Richard Purdie
 

On Fri, 2021-10-15 at 03:03 -0700, Chuck Wolber wrote:
Is there a recommended strategy to get do_fetch to invalidate on directory
path changes in paths pointed to by file:// URLs in SRC_URI?

Example:

SRC_URI += "file://src;subdir=${S}"

A file at src/foo/bar/baz is recognized just fine. But then a directory change
to something like src/foo/bar2/baz is not recognized and does not invalidate
any tasks in subsequent builds.

Use case is a recipe that has a fair bit of metadata that is not even remotely
amenable to the typical flat layout expected of a set of patches.

..Ch:W..

P.S. I attempted to do this with an event handler that was run when
bb.event.RecipePreFinalise is is fired. It would compare directory trees and
set do_fetch[nostamp] = "1" to invalidate the fetcher task. But I got really
spotty behavior. It seems like event handlers are cached like tasks.
I can see why this breaks and it isn't entirely straightforward to fix since
we'd have to add data to the file-checksums entries which are generated by both
OE and Bitbake.

I have a bit of a horrible idea to do this in master-next which does solve the
problem. We probably need a new bitbake selftest testcase before I could think
about merging it though.

Cheers,

Richard


[PATCH][meta-selinux][dunfell] MAINTAINERS: update email address

Mikko Rapeli
 

From: Armin Kuster <akuster808@...>

Include example send-email

Signed-off-by: Armin Kuster <akuster808@...>
Signed-off-by: Joe MacDonald <joe@...>
(cherry picked from commit 48038b45dc114592991c069eb66d174820c0701d)
---
MAINTAINERS | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36c451f..0dc492e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,7 +1,14 @@
This file contains a list of maintainers for the meta-selinux layer.

Please submit any patches against meta-selinux to the Yocto Project mailing
-list (yocto@...).
+list (yocto@...).
+
+git send-email -1 --to yocto@... --subject-prefix=meta-selinux][PATCH
+
+These values can be set as defaults for this repository:
+
+$ git config sendemail.to yocto@...
+$ git config format.subjectPrefix meta-selinux][PATCH

You may also contact the maintainers directly.

--
2.20.1


[PATCH][meta-selinux][dunfell] libselinux: Backport NULL pointer fix from 3.1

Jonas Brich
 

From: Mikko Rapeli <mikko.rapeli@...>

From: Jonas Brich <Jonas.Brich@...>

Using function restorecon_init inside selinux_restorecon.c can
result in a NULL pointer. This happens because function
selinux_restorecon_set_sehandle can return a NULL pointer. But
it is not checked and directly given to the next function.

This problem is already fixed in libselinux 3.1 and above.
Therefore backport this fix.

Signed-off-by: Jonas Brich <Jonas.Brich@...>
---
...e-in-selinux_restorecon_set_sehandle.patch | 32 +++++++++++++++++++
recipes-security/selinux/libselinux_3.0.bb | 1 +
2 files changed, 33 insertions(+)
create mode 100644 recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch

diff --git a/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch b/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch
new file mode 100644
index 0000000..f12164f
--- /dev/null
+++ b/recipes-security/selinux/libselinux/0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch
@@ -0,0 +1,32 @@
+From 08f5e30177218fae7ce9f5c8d6856690126b2b30 Mon Sep 17 00:00:00 2001
+From: Ji Qin <jiqin.ji@...>
+Date: Sun, 14 Jun 2020 21:20:23 -0400
+Subject: [PATCH] libselinux: Fix NULL pointer use in
+ selinux_restorecon_set_sehandle
+
+error occur when selinux_restorecon_default_handle return NULL in
+restorecon_init.
+
+fixes: https://github.com/SELinuxProject/selinux/issues/249
+
+Signed-off-by: Ji Qin <jiqin.ji@...>
+Acked-by: Stephen Smalley <stephen.smalley.work@...>
+---
+ libselinux/src/selinux_restorecon.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+Upstream-Status: Backport [https://github.com/SELinuxProject/selinux/commit/08f5e30177218fae7ce9f5c8d6856690126b2b30]
+
+diff --git libselinux/src/selinux_restorecon.c libselinux/src/selinux_restorecon.c
+index d1ce830c5..6993be6fd 100644
+--- libselinux/src/selinux_restorecon.c
++++ libselinux/src/selinux_restorecon.c
+@@ -1154,6 +1154,8 @@ void selinux_restorecon_set_sehandle(struct selabel_handle *hndl)
+ size_t num_specfiles, fc_digest_len;
+
+ fc_sehandle = (struct selabel_handle *) hndl;
++ if (!fc_sehandle)
++ return;
+
+ /* Check if digest requested in selabel_open(3), if so use it. */
+ if (selabel_digest(fc_sehandle, &fc_digest, &fc_digest_len,
diff --git a/recipes-security/selinux/libselinux_3.0.bb b/recipes-security/selinux/libselinux_3.0.bb
index 17a25a9..01f9b7b 100644
--- a/recipes-security/selinux/libselinux_3.0.bb
+++ b/recipes-security/selinux/libselinux_3.0.bb
@@ -13,4 +13,5 @@ SRC_URI += "\
file://libselinux-define-FD_CLOEXEC-as-necessary.patch \
file://0001-Fix-building-against-musl-and-uClibc-libc-libraries.patch \
file://0001-libselinux-export-flush_class_cache-call-it-on-polic.patch \
+ file://0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch \
"
--
2.20.1


SRC_URI Directory Change

Chuck Wolber
 

Is there a recommended strategy to get do_fetch to invalidate on directory path changes in paths pointed to by file:// URLs in SRC_URI?

Example:

SRC_URI += "file://src;subdir=${S}"

A file at src/foo/bar/baz is recognized just fine. But then a directory change to something like src/foo/bar2/baz is not recognized and does not invalidate any tasks in subsequent builds.

Use case is a recipe that has a fair bit of metadata that is not even remotely amenable to the typical flat layout expected of a set of patches.

..Ch:W..

P.S. I attempted to do this with an event handler that was run when bb.event.RecipePreFinalise is is fired. It would compare directory trees and set do_fetch[nostamp] = "1" to invalidate the fetcher task. But I got really spotty behavior. It seems like event handlers are cached like tasks.


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


[meta-cgl][PATCH] libsocket6-perl: inherit autotools-brokensep

Yi Zhao
 

Inherit autotools-brokensep to fix the build error which is introduced
by oe-commit:
commit 8e26252b45b7660c7c67c702411bdec187a76ffc
Author: Richard Purdie <richard.purdie@...>
Date: Sun Sep 19 16:17:31 2021 +0100

layer.conf: Extend recipes not to install without explict dependencies

Fixes:
libsocket6-perl/0.29-r2/temp/run.do_configure.27951: autoreconf: not found
libsocket6-perl/0.29-r2/temp/run.do_configure.27951: oefatal: not found

Signed-off-by: Yi Zhao <yi.zhao@...>
---
meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb b/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
index bbeab8e..9f38380 100644
--- a/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
+++ b/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
@@ -23,4 +23,4 @@ do_configure:prepend () {
sed -i 's:\./configure\(.[^-]\):./configure --build=${BUILD_SYS} --host=${HOST_SYS} --target=${TARGET_SYS} --prefix=${prefix} --exec_prefix=${exec_prefix} --bindir=${bindir} --sbindir=${sbindir} --libexecdir=${libexecdir} --datadir=${datadir} --sysconfdir=${sysconfdir} --sharedstatedir=${sharedstatedir} --localstatedir=${localstatedir} --libdir=${libdir} --includedir=${includedir} --oldincludedir=${oldincludedir} --infodir=${infodir} --mandir=${mandir}\1:' Makefile.PL
}

-inherit cpan
+inherit autotools-brokensep cpan
--
2.25.1


Re: glibc -fstack-protector-strong

Khem Raj
 

On 10/14/21 7:35 PM, Paul Eggleton wrote:
Hi folks
I'm looking at how -fstack-protector-strong might be enabled in the glibc
recipe. It looks like it should already be enabled by default via
--enable-stack-protector=strong in EXTRA_OECONF, however looking at the
compile logs it is passing -fno-stack-protector instead. Examining the
configure log:
checking for -fstack-protector... (cached) no
checking for -fstack-protector-strong... (cached) no
checking for -fstack-protector-all... (cached) no
This in turn comes from libc_cv_ssp_strong=no in CACHED_CONFIGUREVARS in
glibc.inc. Searching back through the git history I can't find much by way of
explanation as to why the stack protector options are disabled. Setting
libc_cv_ssp_strong=yes however results in the following:
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os \
| -Wl,-d -Wl,--whole-archive /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map.o \
| '-Wl,-(' /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.mapT
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:499: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf'
| make[1]: *** [Makefile:490: elf/subdir_lib] Error 2
| make[1]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git'
| make: *** [Makefile:9: all] Error 2
| ERROR: oe_runmake failed
This is not an area I have looked much into before; does anyone have any insights?
This was enabling ssp support in glibc not only for other programs but also for rest of glibc components during compile and that resulted in duplicate symbols, IIRC thats why we disabled it, the error you are seeing looks that we still have that problem lurking around. Unfortunately I dont have a solution handy to offer

Thanks
Paul


glibc -fstack-protector-strong

Paul Eggleton
 

Hi folks

I'm looking at how -fstack-protector-strong might be enabled in the glibc
recipe. It looks like it should already be enabled by default via
--enable-stack-protector=strong in EXTRA_OECONF, however looking at the
compile logs it is passing -fno-stack-protector instead. Examining the
configure log:

checking for -fstack-protector... (cached) no
checking for -fstack-protector-strong... (cached) no
checking for -fstack-protector-all... (cached) no

This in turn comes from libc_cv_ssp_strong=no in CACHED_CONFIGUREVARS in
glibc.inc. Searching back through the git history I can't find much by way of
explanation as to why the stack protector options are disabled. Setting
libc_cv_ssp_strong=yes however results in the following:

| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os \
| -Wl,-d -Wl,--whole-archive /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.os
| x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now -fuse-ld=bfd -nostdlib -nostartfiles -r -o /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map.o \
| '-Wl,-(' /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.mapT
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__GI___libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.3.0/ld.bfd: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/libc_pic.a(libc_fatal.os): in function `__GI___libc_fatal':
| /usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/libio/../sysdeps/posix/libc_fatal.c:161: multiple definition of `__libc_fatal'; /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/dl-allobjs.os:/usr/src/debug/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf/dl-minimal.c:188: first defined here
| collect2: error: ld returned 1 exit status
| make[2]: *** [Makefile:499: /media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/build-x86_64-poky-linux/elf/librtld.map] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git/elf'
| make[1]: *** [Makefile:490: elf/subdir_lib] Error 2
| make[1]: Leaving directory '/media/large/oe/poky/tmp/work/core2-64-poky-linux/glibc/2.31+gitAUTOINC+4f0a61f753-r0/git'
| make: *** [Makefile:9: all] Error 2
| ERROR: oe_runmake failed

This is not an area I have looked much into before; does anyone have any insights?

Thanks
Paul


Re: docker fragment missing conntrack and netfilter entries? #meta-virtualization

Bruce Ashfield
 

On Thu, Oct 14, 2021 at 12:23 PM <crawford.benjamin15@...> wrote:

Hi,

I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.

Shouldn't the following be added: (?)

CONFIG_NETFILTER_NETLINK=m
CONFIG_NT_CT_NETLINK=m

CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
FYI: you want the meta-virtualization mailing list, not the main yocto
one for questions like this.

There's a balancing act with the fragments: they are as
non-overlapping as possible, they often support a wide range of kernel
versions and kernel providers, so there are sometimes more, or less
options than you'd expect in a fragment.

In particular the fragments in meta-virtualization are changing right
now, and are being unified in the kernel-cache repository (that allows
the duplicated options to be rationalized).

So depending on which docker.cfg you are looking at, you'd either send
a patch to the linux-yocto mailing list, or the meta-virtualization
list.

In particular, the netfilter fragment is what is expected to provide
many of the needed options, and that's what has been happening with
the out of box docker, lxc, podman, k8s, etc, configurations tested in
meta-virt. The docker.scc fragment will start pulling that in
automatically as part of the de-duplication effort I hinted at above.

But there's no harm in sending a patch, I'll figure out how/where it
applies as I go through those efforts.

Cheers,

Bruce







Thanks,
Ben




--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


[PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Alexander Kanavin
 

From: Alexander Kanavin <alex@...>

In addition to the testresult json, testimage class now also
provides the testimage task log and qemu console output log
which can be useful for debugging test failures or
even checking qemu test runs when failures did not happen.

Rather than duplicate specific file/folder names, let's copy all
that is available, and define what is published in the testimage
class itself (with appropriate folder structure if/when needed).
At the moment there's just three files, and they are copied into
folders named after image names, so there's no clutter or risk
of mixing them up with unrelated logs.

[YOCTO #14518]

Signed-off-by: Alexander Kanavin <alex@...>
---
scripts/collect-results | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/collect-results b/scripts/collect-results
index 93834d6..7caa177 100755
--- a/scripts/collect-results
+++ b/scripts/collect-results
@@ -3,11 +3,9 @@ WORKDIR=$1
DEST=$2
target=$3

-RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
-
-if [ -e $RESFILE ]; then
- mkdir -p $DEST/$target
- cp $WORKDIR/tmp/log/oeqa/testresults.json $DEST/$target/
+mkdir -p $DEST
+if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
+ cp -Lrf $WORKDIR/tmp/log/oeqa/ $DEST/$target
fi

if [ -e $WORKDIR/buildhistory ]; then
--
2.31.1


Re: docker fragment missing conntrack and netfilter entries? #meta-virtualization

Khem Raj
 

On 10/14/21 9:23 AM, crawford.benjamin15@... wrote:
Hi,
I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.
Shouldn't the following be added: (?)
|CONFIG_NETFILTER_NETLINK=m|
|CONFIG_NT_CT_NETLINK=m|
|CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
seems fine. Please send a patch for enhancing it via docker.cfg

Thanks,
Ben|


Re: [PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Alexander Kanavin
 

On Thu, 14 Oct 2021 at 18:08, Richard Purdie <richard.purdie@...> wrote:
Since that build directory contains symlinks, we may need something like cp -L
here? I didn't test but I think we might run into an issue?

That's right, -L is needed.

Alex


docker fragment missing conntrack and netfilter entries? #meta-virtualization

crawford.benjamin15@...
 

Hi,

I have just completed a bringup of Poky on the ODROID N2+ platform, but noticed that Docker failed to start, complaining that it could not load the "nf_conntrack_netlink" module.
After checking docker.cfg, I noticed that a few configuration options I expected were missing.

Shouldn't the following be added: (?)

CONFIG_NETFILTER_NETLINK=m
CONFIG_NT_CT_NETLINK=m

CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m

Thanks,
Ben


Re: [PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa/

Richard Purdie
 

On Wed, 2021-10-13 at 18:18 +0200, Alexander Kanavin wrote:
From: Alexander Kanavin <alex@...>

In addition to the testresult json, testimage class now also
provides the testimage task log and qemu console output log
which can be useful for debugging test failures or
even checking qemu test runs when failures did not happen.

Rather than duplicate specific file/folder names, let's copy all
that is available, and define what is published in the testimage
class itself (with appropriate folder structure if/when needed).
At the moment there's just three files, and they are copied into
folders named after image names, so there's no clutter or risk
of mixing them up with unrelated logs.

[YOCTO #14518]

Signed-off-by: Alexander Kanavin <alex@...>
---
scripts/collect-results | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/collect-results b/scripts/collect-results
index 93834d6..3663330 100755
--- a/scripts/collect-results
+++ b/scripts/collect-results
@@ -3,11 +3,9 @@ WORKDIR=$1
DEST=$2
target=$3

-RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
-
-if [ -e $RESFILE ]; then
- mkdir -p $DEST/$target
- cp $WORKDIR/tmp/log/oeqa/testresults.json $DEST/$target/
+mkdir -p $DEST
+if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
+ cp -rf $WORKDIR/tmp/log/oeqa/ $DEST/$target
fi
Since that build directory contains symlinks, we may need something like cp -L
here? I didn't test but I think we might run into an issue?

Cheers,

Richard


Minutes: Yocto Project Weekly Triage Meeting 10/14/2021

Kiran Surendran
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Steve, Randy, Bruce, Ross, Richard, Alexandre, Tim, Joshua, Kiran

ARs: NONE


Notes: NONE


Medium+ 3.4 Unassigned Enhancements/Bugs: 68 (No change)

Medium+ 3.5 Unassigned Enhancements/Bugs: 12 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (No change)

AB Bugs:  65 (Last week 64)


[PATCH yocto-autobuilder-helper] config.json: build FVP-Base instead of N1SDP

Ross Burton <ross@...>
 

FVP-Base is a better supported and more generally useful machine than N1S=
DP.

Signed-off-by: Ross Burton <ross.burton@...>
---
config.json | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 0fe1f1a..dd890fe 100644
--- a/config.json
+++ b/config.json
@@ -324,11 +324,13 @@
"${BUILDDIR}/../meta-arm/meta-arm-bsp"
],
"step1": {
- "MACHINE": "n1sdp",
+ "shortname": "Build for fvp-base",
+ "MACHINE": "fvp-base",
"BBTARGETS": "core-image-minimal core-image-sato core-im=
age-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-sato:do_testsdk"
},
"step2": {
+ "shortname": "Build for juno",
"MACHINE": "juno",
"BBTARGETS": "core-image-minimal core-image-sato core-im=
age-sato:do_populate_sdk",
"SANITYTARGETS" : "core-image-sato:do_testsdk"
--=20
2.25.1


Re: #zeus meta-intel #zeus

Monsees, Steven C (US)
 

Thank you.

I will most likely look into creating a dunfell based build this weekend...
My current system is zeus based, centos, still using sysvinit on startup...

Did run using clang 9.0 ?

I appreciate your time and trouble,
Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Wednesday, October 13, 2021 9:28 PM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


There are no patches needed other than what is already in oe-core/meta- intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see any problem.

zeus is no longer maintained or supported so I'd suggest checking a newer release or experimenting without using buildtools to see if that is exposing this problem. It does look like things are not being compiled properly or perhaps opencl-clang-native is linking to incorrect LLVM ...

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +0000, Monsees, Steven C (US) wrote:

Anything ?, I have yet to resolve this.

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 9:03 AM
To: 'Mittal, Anuj' <anuj.mittal@...>;
'yocto@...' <yocto@...>
Subject: RE: [yocto] #zeus meta-intel


Are there any patches required for these components (igc, opencl-
clang, and intel-compute-runtime) ?

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' <anuj.mittal@...>;
yocto@...
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

This email has been sent from an account outside of the BAE Systems
network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.
For further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


Did you build everything with this compiler from start? Is opencl-
clang building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +0000, Monsees, Steven C (US) wrote:

Anuj:

I picked up the tarball for for the baseline dunfell tools platform
to update host tools...

I am seeing it compile cleaner but for one issue causng ld to fail:

/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'

Isn't LLVM brought in along with clang under meta-clang ?

Is there a missing build dependency ?

Thanks,
Steve

Build excerpt showing multiple " undefined reference to `vtable "
errors...

/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >
::opt<llvm::cl::FormattingFlags, llvm::cl::desc,
llvm::cl::desc const&, llvm::cl::initializer<char [2]> const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::opt<char [9],
llvm::cl::desc>(char const (&) [9], llvm::cl::desc const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
collect2: error: ld returned 1 exit status

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Anuj Mittal
Sent: Tuesday, October 12, 2021 10:43 AM
To: Monsees, Steven C (US) <steven.monsees@...>;
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

network.

Please treat the email with caution, especially if you are requested
to click on a link, decrypt/open an attachment, or enable macros.
For
further information on how to spot phishing, access “Cybersecurity
OneSpace Page” and report phishing by clicking the button “Report
Phishing” on the Outlook toolbar.


On Tue, 2021-10-12 at 12:43 +0000, Monsees, Steven C (US) wrote:
g++: error: unrecognized command line option ‘-std=c++14’
It looks like the gcc version is too old on your host for this to
work.

Thanks,

Anuj

2761 - 2780 of 57813