bismuth icon indicating copy to clipboard operation
bismuth copied to clipboard

[DEV]: Compile problem on different architectures

Open onuralpszr opened this issue 2 years ago • 1 comments

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

onuralpszr avatar Aug 08 '22 10:08 onuralpszr

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

pinotree avatar Oct 30 '22 08:10 pinotree