Description of problem: After upgrade to latest build list of supported hardware becomes empty. All dependent programs refuses to work. Version-Release number of selected component (if applicable): libsigrok-0.5.2-3.fc33.x86_64 How reproducible: Always Steps to Reproduce: 1. Update to new libsigrok, install sigrok-cli 2. sigrok-cli -L Actual results: Supported hardware drivers: Supported input formats: binary Raw binary logic data Expected results: After downgrade to libsigrok-0.5.2-2.fc32.x86_64: sigrok-cli -L Supported hardware drivers: agilent-dmm Agilent U12xx series DMMs appa-55ii APPA 55II arachnid-labs-re-load-pro Arachnid Labs Re:load Pro .... long long list Additional info: Manual rebuild does not help.
Build without LTO - all OK.
Thanks for trying, there are many issues revealed by enabling LTO. This issue points more to a bug in libsigrok itself than anything else (glib2 perhaps?). Could you open an upstream bug for it?
Hmm, I can't reproduce the reported behaviour, I'm always getting the full list of the device/drivers. Can you provide more details about your environment? Is it a fresh install of Rawhide or F-33? Or do you get it also in mock's chroot? Can you attach "rpm -qa" output (all installed rpms)?
Created attachment 1715638 [details] List of installed packages It's not a fresh install. It's a host (working device) with long history and additional self-made packages (*.xf\d\d.*)
I get the same problem with sigrok-cli and pulseview, my system is Fedora 33, fresh install The same problem is reported with root account The AppImage downloaded from sigrok site (https://sigrok.org/wiki/Downloads )works very well.
I can confirm this issue on Fedora 33 x86_64. There is an upstream bug report: https://sigrok.org/bugzilla/show_bug.cgi?id=1433. Also, there is a fix from OpenSUSE developers. I added patch from OpenSUSE into Fedora package: https://src.fedoraproject.org/rpms/libsigrok/pull-request/1
Ivan, thanks for the bug link and the PR. Could you poke the upstream developers about it, please? The fix hasn't been merged yet, if I see right. I would rather disable LTO in our build than merge a non-upstream fix.
Dan, I found a simpler fix and posted it on Sigrok's Bugzilla. Let's wait for an answer there. I hope that my version is more "mainlineable".
Thanks, Ivan, yes, your fix is much more straightforward and could be merged downstream. Jeff, could you, please, take a look at this LTO-related problem? The details are in the upstream ticket (in comment #6).
FEDORA-2020-180c961a3b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-180c961a3b
FEDORA-2020-180c961a3b has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-180c961a3b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-180c961a3b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
tested libsigrok-0.5.2-4.fc34.x86_64 - works for me
FEDORA-2020-180c961a3b has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
Fundamentally this code from src/drivers.c is broken: for (const struct sr_dev_driver **drivers = sr_driver_list__start + 1; drivers < sr_driver_list__stop; drivers++) g_array_append_val(array, *drivers); The patch referenced in this BZ may work now, but I wouldn't at all be surprised if this breaks again one day. Depending on two distinct objects being ordered in a particular way in memory is just wrong and I'm confident if I had the time to dig through the ISO C/C++ standards that it's got undefined behavior.
Thanks Jeff, I'll pass this info to upstream.