libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by re2c)

[GarethH96]

Using Arch Linux with kernel 5.12.9-arch1-1, running MACHINE=unmatched bitbake demo-coreip-xfce4 in build results in failure. See output: build.log. Replacing build/tmp-glibc/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6 with a symbolic link pointing to /usr/lib/libstdc++.so.6 fixes the issue.

Although, rerunning MACHINE=unmatched bitbake demo-coreip-xfce4 after the adjustment still fails, now spitting out a lot errors saying ISO C++17 does not allow dynamic exception specifications.

[davidlt]

In this case it might be that re2c was built against a different sysroot. Most likely re2c-native did something wrong while building.

Note that ArchLinux is not supported by OE (doesn't mean it shouldn't work). See: http://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions

[davidlt]

Btw, did you use buildtools? ./openembedded-core/scripts/install-buildtools -r yocto-3.2_M2 -t 20200729

[GarethH96]

@davidlt Yes, I used buildtools.

Also, I attempted building on a VM, running Debain Sid (unstable) and managed to get it working after a second try. First try got up to ~90%, but crashed while compiling Clang. On the second try, I got it to work by throwing in a 50GB swap file, even though 32GB of RAM is installed!

I know running out of memory isn't the issue with the native Arch Linux install as that has a ~128 GB swap partition.

[mikedilger]

Also on Arch, I copied /usr/lib/libstdc++.so.6.0.29 into the directory, and made a symlink next to it from libstdc++.so.6

I haven't got the ISO C++17 errors (... yet?) I'm stuck on gdb-10.2 claiming there is no liblzma at about 4100 tasks in of 7070 tasks (even though /usr/lib/liblzma and lzma.h and stuff are all installed).

[yqszxx]

Also on Arch, I copied /usr/lib/libstdc++.so.6.0.29 into the directory, and made a symlink next to it from libstdc++.so.6

I haven't got the ISO C++17 errors (... yet?) I'm stuck on gdb-10.2 claiming there is no liblzma at about 4100 tasks in of 7070 tasks (even though /usr/lib/liblzma and lzma.h and stuff are all installed).

Got the same liblzma error on arch (

[jim-wilson]

I tried looking at this.

The lzma problem is because open embedded is trying to build riscv-oe-linux gdb, and gdb configure found the native x86_64 liblzma in /usr/lib, which obviously won't work with a riscv64-linux toolchain. OE needs to make sure that the native dirs aren't on the search path, or pass a --with-liblzma-prefix= option. Or maybe this is a gdb configure bug. Or don't try to enable the lzma support. Or temporarily uninstall the native liblzma package for the OE build. Though it looks like a RISC-V liblzma was built first and put in the sysroot, so not obvious what went wrong. The problem doesn't happen on Ubuntu because it is a multiarch machne and liblzma is installed in a dir like /usr/lib/x86_64-linux-gnu that a RISC-V toolchain will never look in, nor will a gdb configure look there by default. This needs more investigation. I hacked around the problem for now by commenting out the PKGCONFIG lzma line in openembedded-core/meta/recipes-devtools/gdb/gdb-common.in.

The problem here is similar to a problem that the buildroot folks ran into. https://patchwork.ozlabs.org/project/buildroot/patch/[email protected]/

I didn't hit the libstdc++.so problem. Or at least haven't hit it yet.

I did get a linker error for webkit but that looks like an oom-killer problem. I've got 8GB of ram and 8GB of swap which should be enough. I've restarted the build. Maybe too many things were building at one time and caused the memory to run out.

[jim-wilson]

I needed 24GB to link webkit. Then the build failed due to running out of disk space. I shouldn't have tried to build an xfce4 image on this laptop.

Anyways, for the lzma checking the Yocto docs I found that PACKAGECONFIG can have more than one option, and there is expat support in gdb that does exactly what we need for lzma showing me the correct variable to use for the host sysroot. That gives me a patch that appears to work fine, though the image is still building so I haven't had a chance to run it yet to test it

diff --git a/meta/recipes-devtools/gdb/gdb-common.inc b/meta/recipes-devtools/gdb/gdb-common.inc
index 0fe7b4e5b0..96e20b4f2e 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -36,7 +36,7 @@ PACKAGECONFIG[python] = "--with-python=${WORKDIR}/python,--without-python,python
 PACKAGECONFIG[babeltrace] = "--with-babeltrace,--without-babeltrace,babeltrace"
 # ncurses is already a hard DEPENDS, but would be added here if it weren't
 PACKAGECONFIG[tui] = "--enable-tui,--disable-tui"
-PACKAGECONFIG[xz] = "--with-lzma,--without-lzma,xz"
+PACKAGECONFIG[xz] = "--with-lzma --with-liblzma-prefix=${STAGING_DIR_HOST},--without-lzma,xz"
 PACKAGECONFIG[debuginfod] = "--with-debuginfod, --without-debuginfod, elfutils"
 
 GDBPROPREFIX = "--program-prefix=''"

In case the copy paste didn't work right, here is the patch as an attachment. arch-gdb-lzma.txt . This is a generic OE problem, so this patch should go upstream.

[jim-wilson]

My cli image build finished, booted it in qemu, and gdb is linked against liblzma and runs OK.

[jim-wilson]

Submitted upstream. My first OE patch so I don't know how well this will work. https://lists.openembedded.org/g/openembedded-core/message/158320

[jim-wilson]

My patch was committed upstream last week. https://github.com/openembedded/openembedded-core/commit/56623848f45cf475f909beb75209323a89837169

[tprrt]

This issue is no longer relevant.