## Context

In the past few months, I have been fixing all frameworks to support static linking, link time optimizations and profile guided optimizations. So far the patches are a little crude and are not in mergeable shape. Since yesterday I cleaned up a few of them to begin the upstreaming process. There's already an elv13/fix_static branch for 2 frameworks to discuss the changes. LTO and static mode enables KDE apps to be built in a single binary that's about ~10mb for most applications, 20mb for big ones due to the assets, making it small enough for even low end mobile devices. It's also starting much faster thanks to the PGOs.

Most frameworks "work" after some boring build system patches such as fixing common "there is a cmake macro/variable for that, don't write your own code" type of bugs. There's also the need to make QtTest optional everywhere to avoid having hundreds of gigabytes worth of tests being built (and it takes a looooong time to link). However some frameworks are really broken such as the ones with plugins and those abusing of undefined behavior or static initialization behavior, such as KConfigGui.

## The bug

This warning is hit and kcolorsheme fail to load, rendering all applications black on black (invalid QColor).

 372     case QMetaType::QColor:
 373     case QMetaType::QFont:
 374         qWarning() << "KConfigGroup::readEntry was passed GUI type '"
 375                    << aDefault.typeName()
 376                    << "' but KConfigGui isn't linked! If it is linked to your program, "
 377                    "this is a platform bug. Please inform the KDE developers";
 378         break;

This is due to several C++ broken features used together.

1) The visitor KConfig uses to have types provided by KConfigGui and not KConfigCore is using static initialization in the form of:

193 static int initKConfigGroupGui()
194 {
195     _kde_internal_KConfigGroupGui.readEntryGui = readEntryGui;
196     _kde_internal_KConfigGroupGui.writeEntryGui = writeEntryGui;
197     return 42;                  // because 42 is nicer than 1 or 0
198 }
199 
200 #ifdef Q_CONSTRUCTOR_FUNCTION
201 Q_CONSTRUCTOR_FUNCTION(initKConfigGroupGui)
202 #else
203 static int dummyKConfigGroupGui = initKConfigGroupGui();
204 #endif

In a CPP file. This is problematic for several reasons:

1) Static initialization order is undefined behavior and changes from compilers to compilers and the level of optimizations used. Having fixed "most" common scenarios with "most" common compilers does not make it predictable. In this case it isn't called at all (and this is actually valid, not a bug due to point 1, 2 and 3 being combined)

2) This is implemented as a `static` variable in a `cpp` file. Static elements in a compilation units are never exported (as defined in the C standard). Even adding __attribute(used), volatile or an EXPORT macro in front wont export it. The compiler is free to apply dead code elimination on these variables if it thinks they are unused or used in UB ways only.

3) The macro is in a cpp file with no header and no exported symbols at all. The link time optimizer uses a reacheability tree purge unused compilation units and sections. There is nothing at all pointing to this CU, it's eliminated from the final executable in GCC and probably all other compilers.

## Is it a compiler bug?

No. It is a certain interpretation of the standard where GCC takes some extra liberty to purge code even if it does "something". It probably fail to resolve that the code actually affects static initialization of other CUs. Given that's undefined anyway, then so be it.

## How can it be fixed

My crude hack is to put `int dummyKConfigGroupGui` in a dummy class and exporting it then print dummyKConfigGroupGui from main.cpp. It fixes the framework and applications are no longer black on black. Obviously it's a bad hack.

The proper way to fix this would be to share createColorEntry in a private KConfigGui header and turn the int into a `static std::atomic_flag KCongigGui::init_flag {ATOMIC_FLAG_INIT};`. Then, in KConfigSkeleton constructor, check the flag and initialize it if it's not already initialized.

This would provide an internal reachability path for `dummyKConfigGroupGui` from the outside of `src/gui/kconfiggroupgui.cpp` and avoid it from being dead-code-eliminated by the compiler.

## tl;dr

Q_CONSTRUCTOR_FUNCTION can't be used in a .cpp file that exports nothing at all. I don't think there's anything that can be done to fix the macro, the compiler will skip it anyway.