Summary: | emulators/qemu-user-static: please add syscall 574 (__realpathat) | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Martin Birgmeier <d8zNeCFG> |
Component: | Individual Port(s) | Assignee: | Kyle Evans <kevans> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | emulation, kevans |
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(emulation) |
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Martin Birgmeier
2020-05-17 14:20:06 UTC
Hi, Indeed, the latest version not yet in ports does have all the latest syscalls. New version is waiting for tracking down a signal regression from back in October that prevents build of cmake and others with the current port. Thanks Kyle for the quick feedback & all your work. -- Martin Yup- I should have mentioned, if you do or are willing to build your own qemu-user-static port, I have a patch available here that updates it to a version that implements most of the latest syscalls and seemingly fixes issues with multi-threaded stuff: https://reviews.freebsd.org/D24655 -> It doesn't fix the aforementioned signal regression, but it's generally stable. Thank you, building right now. Is the "signal regression" the issue where qemu would simply stop while emulating a program? - I have this all the time and then need to ^c and restart. -- Martin Nope, as far as I can test that particular issue is fixed in the patch I've posted- I managed to build guile2 for aarch64 thrice without a hangup. The signal issue generally results in a segfault and prompt build failure. Ok understood. The build just finished, so now off to building armv6 ports... the noise is already gone, thanks for that! And if I understand correctly the hangs should also be gone - looking forward to see that! -- Martin Your patches are working nicely. I could not build binutils using emulation before because the configure stage was producing incorrect results. Now it is happily chugging along... -- Martin Hi Kyle, Some feedback: I am in the process of recompiling all ports for this armv6 installation after upgrading FreeBSD to head as of r361029. I have noticed two things: First, there are still the hangs. They seem to mostly (only?) occur with running ld (lld), and then also mostly if that process is the end of a deep sequence of nested processes. So maybe this has something to do with some resource which gets exhausted by qemu? Maybe some file descriptor? (Maybe ld opens many file at the same time?) Second, and this is new with the qemu built with your patch, some emulated programs result in an immediate signal 11, dumping a core for qemu. These programs are currently xgettext (from gettext-tools-0.20.2) and xmlcatalog (from libxml2-2.9.10); both of these ports have already been recompiled. Is it this issue when you mention the "signal regression"? It is not even possible to run ldd on these binaries; "ldd /usr/local/bin/xgettext" results in the same immediate signal 11 core dump (of qemu). Note that cmake-3.17.2 has been rebuilt successfully, but building glib20 (which needs xmlcatalog during building) is now not possible. -- Martin |