| Summary: | qt5base-5.11.1 Assertion failed: ret == 0 after getentropy() inside fillBuffer() on arm | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Philipp Richter <richterphilipp.pops> |
| Component: | Other | Assignee: | Peter Seiderer <ps.report> |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | buildroot, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Config file used to build | ||
|
Description
Philipp Richter
2018-09-12 10:10:57 UTC
(In reply to Philipp Richter from comment #0) From the getentropy() man page [1] I would suspect an errno 'ENOSYS - This kernel version does not implement the getrandom(2) system call required to implement this function.', your could verify this through additioanl debug statements or strace? [1] http://man7.org/linux/man-pages/man3/getentropy.3.html (In reply to Peter Seiderer from comment #1) Ah yes that might well be the case, thanks. I'm stuck with 3.10.107 on my odroid-c1 unfortunately. I need to do some more testing but what I know right now is that with qt5base-5.6 LTS it starts correctly. I'll also try the config with only arch changes on my raspberry pi which has a much newer kernel. qt5 seems a bit frustrating on some archs haha (In reply to Philipp Richter from comment #2) That is the downside if your are stuck to a vendor kernel, but according to [1] you can try (experimental) linux kernel mainline support... [1] https://github.com/umiddelb/armhf/wiki/How-To-compile-a-custom-Linux-kernel-for-your-ARM-device (In reply to Peter Seiderer from comment #3) I've tried that in the past but there's still too much missing or partially implemented in mainline for it to work. I'm keeping an eye on http://linux-meson.com/doku.php for S805, meson8b to see the progress. But then again newer boards have a higher priority which is understandable. I found out that on archlinux arm for qt5base they have : -no-reduce-relocations -no-feature-getentropy enabled in the the configure options by default. See: https://github.com/archlinuxarm/PKGBUILDs/blob/master/extra/qt5-base/PKGBUILD So I added -no-feature-getentropy to the custom configure options in buildroot like this: BR2_PACKAGE_QT5BASE_CUSTOM_CONF_OPTS="-no-feature-getentropy" And it's all well now, working with latest qt5base. No issue on Raspberry Pi btw so the culprit is of course the old kernel. I'm not sure where to go with this now, it's an edge case of my particular setup. Maybe having an explicit config option appear on the qt5base package for getentropy() might be useful for people restricted by an old kernel version ? Or a hint on a wiki might be enough. Peter, how can we make progress with this issue? To me, it is weird that such things are not auto-detected. It should be known by looking at the kernel headers whether the getentropy() system call is supported or not. It shouldn't be needed to explicitly tell Qt about this. (In reply to Thomas Petazzoni from comment #5) I believe Qt is using the glibc function/wrapper [1] and is already checking for availability of it [2] at configure time and further assumes the running kernel supports it (no returning ENOSYS, maybe this part could be improved on the qt side), or add the -no-feature-getentropy to buildroot if the selected kerne does not support it? [1] http://man7.org/linux/man-pages/man3/getentropy.3.html [2] http://code.qt.io/cgit/qt/qtbase.git/tree/config.tests/unix/getentropy Thank you for your report.
The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
https://gitlab.com/buildroot.org/buildroot/-/issues
We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.
Thank you!
|