[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1791796] Re: unimplemented thread syscalls in nios
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [Bug 1791796] Re: unimplemented thread syscalls in nios2 user-mode emulation |
Date: |
Tue, 11 Sep 2018 20:03:50 +0100 |
User-agent: |
mu4e 1.1.0; emacs 26.1.50 |
Sandra Loosemore <address@hidden> writes:
> If you need a Nios II GNU/Linux toolchain, I think the most recent
> CodeBench Lite release will work:
>
> https://sourcery.mentor.com/GNUToolchain/subscription42545
Hmm I tried automating that but it seems the installer has GTK
dependencies!?
Setup:
GTK+ Version Check
Setup:
An error has occurred. See the log file
/root/.mentor/logs/20180911185933/.metadata/.log.
address@hidden:/opt# cat /root/.mentor/logs/20180911185933/.metadata/.log
!SESSION 2018-09-11 18:59:36.197
-----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_102
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Framework arguments: -install.once -install.data=/root/.mentor
Command-line arguments: -os linux -ws gtk -arch x86 -install.once
-install.data=/root/.mentor -data /root/.mentor/logs/20180911185933
!ENTRY org.eclipse.osgi 4 0 2018-09-11 18:59:37.407
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
/tmp/sourceryg++-2018.05-5-nios2-linux-gnu.bin_sfx.f9eaefb7/installer/configuration/org.eclipse.osgi/148/0/.cp/libswt-pi-gtk-4530.so:
libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
no swt-pi-gtk in java.library.path
Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so
Can't load library: /root/.swt/lib/linux/x86/libswt-pi-gtk.so
/root/.swt/lib/linux/x86/libswt-pi-gtk-4530.so: libgtk-x11-2.0.so.0:
cannot open shared object file: No such file or directory
Should I just try the tarball approach?
> We're planning on adding user-mode QEMU to the upcoming 2018.11
> release.... that's actually what I've been testing it for. Results on
> the GCC testsuite actually don't look too bad,
OK - I'm a little surprised given the failures I saw in our own
test/tcg/multiarch but it's totally possible that:
- the buildroot toolchain if foobar
- the (ancient) tests need tweaking
but it would be nice if we get to a point that QEMU's internal
linux-user tests also pass.
> but I have a patch I
> haven't submitted yet that's required to make the GDB stub work, and
> there are a lot of GDB test failures I haven't triaged yet.
When you do post the gdb patch feel free to CC me as I've poked around
in that before.
--
Alex Bennée