Hide Forgot
Description of problem: After upgrade to Fedora 32, upon login, I get error window saying Plugin "CPU Frequency Monitor" unexpectedly left the panel, do you want to restart it? and re-executing does not help. Version-Release number of selected component (if applicable): xfce4-cpufreq-plugin-1.2.1-5.fc32.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Add CPU Frequence Monitor to XFCE panel on Fedora 32. Actual results: Error window saying Plugin "CPU Frequency Monitor" unexpectedly left the panel, do you want to restart it? Expected results: It shows up in the panel and starts showing the frequency. Additional info: In ~/.xsession-errors, there is (process:1872): xfce4-panel-wrapper-CRITICAL **: 13:38:58.691: Wrapper cpufreq-21: Failed to open plugin module "/usr/lib64/xfce4/panel/plugins/libcpufreq.so": /usr/lib64/xfce4/panel/plugins/libcpufreq.so: undefined symbol: cpuFreq.
Reproducible for me. xfce4-cpufreq-plugin-1.2.1-5.fc32.x86_64
Confirming. Luckily this command restores it (don't forget to exclude the package from automatic updates afterwards): rpm -Uvh --force xfce4-cpufreq-plugin-1.2.1-3.fc31.x86_64.rpm Mukundan Ragavan applied a patch which probably breaks it: sed -i 's/CpuFreqPlugin \*cpuFreq/extern CpuFreqPlugin \*cpuFreq/' panel-plugin/xfce4-cpufreq-plugin.h
Hmmm ... That was needed for compiling with gcc-10. It compiled properly but clearly does not work. Let me take a look.
Of course, any help/patches are appreciated.
(In reply to Artem S. Tashkinov from comment #2) > Mukundan Ragavan applied a patch which probably breaks it: > By the way, stop claiming I am "missing in action" like you did in bz#1830549. I am never going to be able to reply to bug reports as soon as you would like. I am only volunteering my free time. You opening new reports is only going to add to the noise in my email.
(In reply to Mukundan Ragavan from comment #5) Speaking of having no time: the patch which broke the package was added three months ago. During this time you've never bothered to check whether the package works. As a maintainer you could do that, no? At least once, no? Won't spam bugzilla any longer as it obviously doesn't help anyone.
Someone should fix the proposed patch and send to upstream. Please keep being nice to each other, thanks. We mostly work on packages in our free spare time and don't get paid for neither is it our daily buiness/job.
That said, Xfce is generally not blocking criteria for any Fedora release.
(In reply to Raphael Groner from comment #7) > Someone should fix the proposed patch and send to upstream. > I am not sure if this is really a good patch. I don't use this specific plugin at all and have not had the time to check it unfortunately. That said, sensors-plugin also was FTBFS with gcc-10 and fix for that was considerably more complicated and gcc-10 support may not be on the top of the list for upstream since we are the only ones using it (even Arch I believe is on gcc-9 I think). See sensors plugin bug report - https://bugzilla.xfce.org/show_bug.cgi?id=16436 I will try and see if I can fix it. If not I will write to devel@ again.
It looks like the problem is due to this change in GCC: "GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking." Your change to the spec file changes the variable from multiple definitions to *no* definitions (just declarations). You need to declare it in the header, and define it in exactly one file, as explained at https://gcc.gnu.org/gcc-10/porting_to.html#common
I've pushed a fix to rawhide and f32. rawhide build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44053828 f32 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44053843
FEDORA-2020-15a978c272 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-15a978c272
Please test the update and add karma. If it works somebody should submit the patch upstream to XFCE.
(In reply to Jonathan Wakely from comment #13) > Please test the update and add karma. If it works somebody should submit the > patch upstream to XFCE. Thanks for the analysis. Though, I'd prefer a patch sent to upstream, or isn't needed because of special gcc10 flags in Fedora as downstream?
(In reply to Jonathan Wakely from comment #10) > It looks like the problem is due to this change in GCC: … > You need to declare it in the header, and define it in exactly one file, as > explained at https://gcc.gnu.org/gcc-10/porting_to.html#common The new header should be sent to upstream as a patch.
(In reply to Raphael Groner from comment #15) > The new header should be sent to upstream as a patch. Done.
(In reply to Jonathan Wakely from comment #10) > It looks like the problem is due to this change in GCC: > > "GCC now defaults to -fno-common. As a result, global variable accesses are > more efficient on various targets. In C, global variables with multiple > tentative definitions now result in linker errors. With -fcommon such > definitions are silently merged during linking." > > Your change to the spec file changes the variable from multiple definitions > to *no* definitions (just declarations). > Thanks for the fix Jonathan.
FEDORA-2020-15a978c272 has been pushed to the Fedora 32 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-15a978c272` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-15a978c272 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-15a978c272 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.