bismuth
bismuth copied to clipboard
[DEV]: Compile problem on different architectures
Summary
I was trying to build bismuth on different architecture on fedora and some of them fail due to problem of "Too many signals to create unique bit masks" messages comes from kconfig_compiler and here is the relevant line
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/kconfig_compiler/KConfigHeaderGenerator.cpp#L224
Here is the relevant build errors : https://koji.fedoraproject.org/koji/taskinfo?taskID=90594514
One of the build.log URL : https://kojipkgs.fedoraproject.org//work/tasks/4538/90594538/build.log
I wasn't sure where to report maybe it is a problem of bismuth If not I can go report into kconfig but please check it.
Workaround : I turn off those architecture from build for now once it is fixed, I will re-enable them as well.
Additional info
No response
TL;DR: most likely a bug in kconfig_compiler, fixed in kconfig 5.100.0 (both [1] and [2]).
This kconfig_compiler bug affected all the architectures, not only those when it exited with "Too many signals to create unique bit masks". In case of architectures that "built" (e.g. x86_64), the header for the KConfigXT-based configuration was miscreated:
enum {
signalEnableTileLayoutChanged = 0x1,
[...]
signalLimitTileWidthChanged = 0x80000000,
signalLimitTileWidthRatioChanged = 0x0,
signalNewWindowAsMasterChanged = 0x0,
signalExperimentalBackendChanged = 0x0,
signalBismuthEnabledChanged = 0x0
};
The 0x0
bitmask means it was never signaled that a property was changed, and thus its "changed" signal was never emitted. This affected the following configuration keys:
-
limitTileWidthRatio
-
newWindowAsMaster
-
experimentalBackend
-
bismuthEnabled
I don't know whether this means that certain bits in Bismuth didn't work properly before, or whether this was noticed.
After a bit of debugging, I found the bug (at least I hope there are not others) in kconfig_compiler: it wrongly checked for the number of maximum signals to generate bit masks for, using wrong data types. You can read the "gory details" in the commit message of [2]. According to my local testing, the output is properly generated now, both on architectures where kconfig_compiler did not fail, and where it exited with the aforementioned error message. I also backported the fix (both the two commits) to Debian unstable, and Bismuth built fine on all the architectures.
[1] https://invent.kde.org/frameworks/kconfig/-/commit/1ab5e4898de5d8a274f6fa83d9d1debbd3287444 [2] https://invent.kde.org/frameworks/kconfig/-/commit/6c0acf3be392414bbdfbb7473aa842ee59d65f3d