[gdk-pixbuf] wxWidgets wxCheckBox is not rendered properly on Kubuntu 22.04 (KDE) because loaders.cache file is empty and/or not found

[AenBleidd]

Describe the bug I found a very strange bug with wxWidgets 3.2.4 (not sure related to this particular version, a topic to double check) built with vcpkg on Kubuntu 22.04 (KDE). wxCheckBox is not rendered properly (label is visible, but checkbox itself is completely invisible but reacts on mouse). When wxWidgets is built the normal way (using Makefile and/or cmake), this issue is not present, and wxCheckBox is rendered properly. ~I have a strong feeling that this is not related to the wxWidgets itself, but to the way GTK3 is built by vcpkg, because I see these two warnings in the console (not sure these are really related to this issue, but they appear only on the vcpkg build)~: UPDATE: The Gtk-Warning is important, it basically shows the root cause of the issue.

test.cpp

#include <wx/wx.h>
class Test : public wxApp
{
	public:
		virtual bool OnInit();
};

class MyFrame : public wxFrame
{
	public:
		MyFrame();
	private:
		wxCheckBox* m_checkBox;
};

bool Test::OnInit()
{
	MyFrame* frame = new MyFrame();
	frame->Show(true);
	return true;
}

MyFrame::MyFrame() : wxFrame(NULL, wxID_ANY, "Test", wxPoint(50, 50), wxSize(300, 150))
{
	wxPanel* panel = new wxPanel(this, wxID_ANY);
	m_checkBox = new wxCheckBox(panel, wxID_ANY, "<- Here should be a checkbox", wxPoint(10, 10));
	wxBoxSizer* sizer = new wxBoxSizer(wxVERTICAL);
	sizer->Add(m_checkBox, 0, wxALL, 10);
	panel->SetSizer(sizer);
}

wxIMPLEMENT_APP(Test);

CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
set(CMAKE_TOOLCHAIN_FILE "${CMAKE_CURRENT_SOURCE_DIR}/vcpkg/scripts/builsystems/vcpkg.cmake" CACHE STRING "vcpkg")
project(test CXX)
find_package(wxWidgets CONFIG REQUIRED)
add_executable(test test.cpp)
target_link_libraries(test PRIVATE wx::core wx::base)

vcpkg.json

{
	"name": "test",
	"dependencies":
	[
		{
			"name": "wxwidgets",
			"default-features": false
		}
	]
}

I'll update this ticket if I find new useful information, but I'd be very happy if someone could at least give me a hint what to check to find out the root case of this issue.

Environment

• OS: Kubuntu 22.04 (KDE)
• Compiler: doesn't matter, but in this case gcc 11.4.0 was used

To Reproduce Steps to reproduce the behavior:

1. Install Kubuntu 22.04
2. clone vcpkg
3. Create test program using the files from above
4. See the UI issue like on the second screenshot

Expected behavior wxCheckBox is correctly displayed

Failure logs N/A

Additional context Update 1: After I remove libcolorreload-gtk-module.so, I see the same Gtk-Message is the 'good' application built without vcpkg, but wxCheckBox is still rendered properly. So this first message is not related to this issue. Update 2: Looks like the real issue is with gdk-pixbuf that can't find loaders.cache file or because it's empty.

[Osyotr]

Does GTK use plugins? It's your responsibility to make sure they are available in runtime.

[AenBleidd]

Does GTK use plugins? It's your responsibility to make sure they are available in runtime.

Unfortunately, can't answer this question, but on the same system the application built with vcpkg has this issue, and another one built with system-wide libraries doesn't have it. Any clue what I should do additionally with the application built with vcpkg to make it work properly?

[Osyotr]

Related: https://github.com/altf4/libmelee/issues/74#issuecomment-856431343

[AenBleidd]

OK, in this particular case libpixbufloader-svg.so loader is missing (loaders.cache file generated during the build is empty), that is logically correct since this is a 3rd-party loader, and it's not a part of the gdk-pixbuf library. However, it's possible to overload the path to the loaders.cache file via the environmental variable GDK_PIXBUF_MODULE_FILE, but after I did that I got a lot of errors, and the application finally crashed: UPDATE: the file that is used for overload was installed as a part of the system installation, and when I did the same overload with my other test application that was not build with vcpkg, it was working just fine without any error, that means that the file itself is correct. UPDATE 2: These error message are valid: it was not able to load dynamic modules because gdk-pixbuf was built statically. At this point I don't know how to proceed further, but looks like the issue is bigger than I thought previously.

[AenBleidd]

Ok, theoretically, I can fix this next way:

• change librsvg to build additionally (optionally) the loader for gdk-pixbuf
• add dependency on librsvg (optional) to gdk3 (I can't make it as a dependency of gdk-pixbuf) because librsvg itself depends on gdk-pixbuf
• try to link all this statically
• I'm not sure I can do the same for the dynamic builds of gdk3 and all the dependencies, but let's see
• this is just one of the additional modules (there are couple of dozens of them), so there will still be a bunch of work (not sure I'll have time for all this, but I can try to add additional modules one by one from time to time).

[AenBleidd]

Ok, short summary before I'm ready with the clean PR.

The overall issue is next. KDE has themes, and some of the elements (in my case checkbox and radio button) are described using SVG. When GTK3 loads theme, it uses gdk-pixbuf library to get the graphics for the proper drawing. gdk-pixbuf doesn't support SVG by default. For this purposes (in normal case then gdk-pixbuf is a dynamic library) it uses the list of dynamic plugins that are loaded during runtime. When we build gdk-pixbuf statically, it obviously can't load dynamic plugins. So, I had to add SVG support as a built-in functionality. Dynamic SVG loader for gdk-pixbuf uses librsvg library. The simplest solution is to make add librsvg library as a dependency to the gdk-pixbuf. Unfortunately, that's not so easy, because librsvg uses gdk-pixbuf as its dependency. So, welcome to the circular dependency case. For this purpose I had to decouple librsvg, and make it possible to be built (but not linked statically!!!) without gdk-pixbuf. For the dynamic building there should be no difference (a good topic to test, hopefully someone here can help me with this). But here we have a hidden issue: the current version of librsvg added to the vcpkg is written on C. Later versions of this library are now written in Rust. If somebody will decide to update librsvg to the latest version (when Rust toolchain support will be added to vcpkg), they will be surprised with the amount of work (here, to be completely honest, probably will be me who become surprised, because there is a high chance that I will have to fix that because this is the essential part of the software I maintain, and I have no desire to build it dynamically just because of all this). Other important remark: the solution in the PR is very dirty, and if I'd be the reviewer of it, I'd reject it without any regret. That is why, if anybody will have a better idea of achieving the same - they are very welcome to suggest improvements.

[AenBleidd]

Closing this as 'unsupported' combination. More details here: https://github.com/microsoft/vcpkg/pull/39988#issuecomment-2249109124

[AenBleidd]

Just post it here for anyone who might get this issue as well. I have implemented it with the custom ports (need to be regularly updated manually to follow the upstream changes), and it solved the issue: https://github.com/BOINC/boinc/pull/5718 Since this is more a hack than a real solution, I will not continue any efforts to make these changes available in the vcpkg upstream.

[dg0yt]

The real librsvg problem is being stuck on an insecure outdated version due to needing rust in later versions.