Ya I've tracked it down to when qemu invokes the qemu-oe-bridge-helper
to setup network bridging. This is a shell script that uses /bin/sh, and
as the log indicates, /bin/sh can't find the required symbols to start
up (and qemu fails).
I also see it when runqemu attempt so to invoke the stty program to
cleanup the console after qemu runs for the same reason. This one is a
little easier to fix; I have a prototype patch that only passes the
munged environment that sets LD_PRELOAD when runqemu actually invokes
qemu by passing env= to subprocess. The other process invocations with
subprcess are not passed this environment, so they don't see the
LD_PRELOAD. This doesn't fix the bridge problem however because in that
case, qemu is invoking the script so the script inherits qemu's environment.
On 10/21/22 10:43, Alexander Kanavin wrote:
This is the first time I hear about this - can you find out what is
expecting the symbol, and where it's supposed to come from?
Alex
On Fri, 21 Oct 2022 at 17:27, Joshua Watt <jpewhac...@gmail.com> wrote:
This patch broke runqemu for me when I moved to kirkstone. I get this error:
/bin/sh: symbol lookup error:
/grmn/prj/mrn/alchemy/build/tmp/eng/kirkstone/tetra/sysroots-uninative/x86_64-linux/lib/librt.so.1:
undefined symbol: __libc_unwind_link_get, version GLIBC_PRIVATE
And I'm not sure how to fix it. Reverting this change does resolve the problem.
My host is Ubuntu 20.04
On Fri, Feb 4, 2022 at 2:40 PM Alexander Kanavin <alex.kana...@gmail.com> wrote:
Some of the host distributions build the drivers in a way (RPATH/RUNPATH)
that tricks uninative loader into loading pieces of the host libc, if
the same pieces haven't been previously loaded by native binaries. Mixing
the two libc versions leads to failures.
This change ensures that the correct (uninative) versions are always in use.
Signed-off-by: Alexander Kanavin <a...@linutronix.de>
---
meta/classes/qemuboot.bbclass | 2 +-
scripts/runqemu | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index cc1cbce69d..229bd88527 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -109,7 +109,7 @@ def qemuboot_vars(d):
build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
'KERNEL_IMAGETYPE', 'IMAGE_NAME', 'IMAGE_LINK_NAME',
'STAGING_DIR_NATIVE', 'STAGING_BINDIR_NATIVE',
- 'STAGING_DIR_HOST', 'SERIAL_CONSOLES']
+ 'STAGING_DIR_HOST', 'SERIAL_CONSOLES', 'UNINATIVE_LOADER']
return build_vars + [k for k in d.keys() if k.startswith('QB_')]
do_write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
diff --git a/scripts/runqemu b/scripts/runqemu
index 4e05c1bb15..7d1f85f357 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -460,6 +460,10 @@ class BaseConfig(object):
except subprocess.CalledProcessError as e:
raise RunQemuError("Could not determine the path to dri drivers on the
host via pkg-config.\nPlease install Mesa development files (particularly, dri.pc) on the
host machine.")
os.environ['LIBGL_DRIVERS_PATH'] = dripath.decode('utf-8').strip()
+ uninative_path = os.path.dirname(self.get("UNINATIVE_LOADER"))
+ preload_items = ['libdl.so.2', 'librt.so.1', 'libpthread.so.0']
+ preload_paths = [os.path.join(uninative_path, i) for i in
preload_items]
+ os.environ['LD_PRELOAD'] = " ".join(preload_paths)
def check_args(self):
for debug in ("-d", "--debug"):
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172028):
https://lists.openembedded.org/g/openembedded-core/message/172028
Mute This Topic: https://lists.openembedded.org/mt/88916306/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
