LINUX.ORG.RU

gtk4(или 3) под windows

 , msys64,


0

2

каюсь, второй день матерюсь и не могу пройти квест - собрать хоть что-нибудь gtk4 (hello_word) под windows.

строго по инструкции: поставлен с нуля msys64, тулчайн ucrt ; в качестве hello_word первый-же исходник с https://docs.gtk.org/gtk4/getting_started.html;

сборка тоже оттуда-же, из командной строки, без cmake.

но не работает :

GLib-WARNING (recursed) **: Failed to determine console output code page: Системе не удается найти у
казанный параметр среды.. Falling back to UTF-8

под отладчиком вот :

Thread 1 hit Breakpoint 1, main (argc=1, argv=0x2a6e0904260) at first.c:22
22        app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
(gdb) n
23        g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
(gdb)
24        status = g_application_run (G_APPLICATION (app), argc, argv);
(gdb)
[New Thread 13800.0x31ec]
[New Thread 13800.0xe40]
[New Thread 13800.0x191c]

GLib-WARNING (recursed) **: Failed to determine console output code page: Системе не удается найти у
казанный параметр среды.. Falling back to UTF-8[New Thread 13800.0xe54]
[New Thread 13800.0x6a0]
[New Thread 13800.0x3450]
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(1) tid(9e4) 80070002  .
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(2) tid(9e4) 80070002  .
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(3) tid(9e4) 80070002  .
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(4) tid(9e4) 80070002  .
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(5) tid(9e4) 80070002  .
warning: minio\profapi\registry.cpp(48)\profapi.dll!00007FFA407E4D19: (caller: 00007FFA388DC14C) Ret
urnHr(6) tid(9e4) 80070002  .

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffa40b1df73 in KERNELBASE!DebugBreak () from C:\Windows\System32\KernelBase.dll

сильно подозреваю, что каких-то опций при сборке нехватает, потому как gtk4-demo, gedit и прочие работают.

Что этой скотине в windows нехватило ??

★★★★★

Последнее исправление: MKuznetsov (всего исправлений: 1)

Я подобной фигнёй маялся под виндой, только я не GTK собирал, а одну либу и вместе с ней свою программу. Сначала пробовал собирать через cygwin, потом через msys, словил целую кучу проблем с видимостью библиотек и сборочных программ. У меня знатно так пригорело от всех этих плясок с бубном и потом тупо поставил чистую винду, собрал вручну весь мне нужный тулчей для сборки без всяких там msys'ов и cygwin'ов, прописал вручную пути, им же собрал либу с прогой и только после этого у меня всё заработало.

P. S. Только после этого я понял, какое же это дно собирать что-то на Windows, выходя за рамки Visual Studio.

Dr64h ★★★
()
Последнее исправление: Dr64h (всего исправлений: 1)
Ответ на: комментарий от raspopov

Надо смотреть, выложите полный архив со своими артефактами куда-нибудь.

полный архив чего ? msys64.org ?? столкнувшись с проблемой - посокращал всё что мог..в итоге - чистый msys64.org и компилируется пример из документации gtk

#include <gtk/gtk.h>

static void
activate (GtkApplication* app,
          gpointer        user_data)
{
  GtkWidget *window;

  window = gtk_application_window_new (app);
  gtk_window_set_title (GTK_WINDOW (window), "Window");
  gtk_window_set_default_size (GTK_WINDOW (window), 200, 200);
  gtk_widget_show (window);
}

int
main (int    argc,
      char **argv)
{
  GtkApplication *app;
  int status;

  app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);

  return status;
}

сброка производится :

gcc $( pkg-config --cflags gtk4 ) -o example-0 example-0.c $( pkg-config --libs gtk4 )

ФСИЁ :-)

методом проб и ошибок выяснилось что точно так-же не работают штатные gsettings, gtk4-query-settings и gtk4-builder-tool

сейчас подозреваю что есть какие-то нелады с темами и настройками gtk. Или содержанием и расположением settings.ini; Наухивертили блин..

Заранее ужасаюсь «как нормально переносить/инсталлировать приложение с gtk»

PS/ лишний раз убедился что единственный реально работающий мультиплатформенный тулкит - это Tk; остальные просто источник айтишного секса

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

полный архив чего ?

Артефакты - это результаты сборки проекта: бинарники, библиотеки и всё, что требуется для запуска программы. Обычно, сама попытка собрать всё вместе уже помогает понять, что за чудо получилось, и чего не хватает программе для счастья.

raspopov
()
Ответ на: комментарий от raspopov

Артефакты - это результаты сборки проекта: бинарники, библиотеки и всё, что требуется для запуска программы. Обычно, сама попытка собрать всё вместе уже помогает понять, что за чудо получилось, и чего не хватает программе для счастья.

ещё раз, по буквам - всё штатное. msys2.org свежепоставленный, из пакетов - только toolchain mingw-w64-ucrt-x86_64 base_devel и gtk4 в нём. Сборка из командной строки, строку привёл.

если класть всё в архив - то это вот прямо таки весь msys64.

чтобы повторить попытку, заинсталить из https://www.msys2.org/, а далее:

pacman -S mingw-w64-ucrt-x86_64-toolchain base-devel mingw-w64-ucrt-x86_64-gtk4 

дальше берём первый-же исходник из https://docs.gtk.org/gtk4/getting_started.html и приведённой с ним командной строкой собираем.

собирается, но не работает. Кстати вне зависимости от toolchain - с более традиционным mingw-w64-x86_64-toolchain (не ucrt) то-же самое.

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от EXL

А там нет никакого GTK+ static или подобных пакетов?

нету..я уже перечислил все установленные пакеты.

может с виндовс-хостом что не так, какая-нить запись в реестре не туда показывает..но это-же не повод так «падать» в тулчайн-окружении.

и опять-же gtk4-demo работает, gedit работает. А не работает элементарный hello-word и вышеуказанные несколько утилит.

MKuznetsov ★★★★★
() автор топика

А не ucrt работает?

pacman -S mingw-w64-x86_64-toolchain base-devel mingw-w64-x86_64-gtk4 

?

У меня всё работало без каких-либо плясок с бубном…

Сейчас gtk не установлен. Но я не использовал ucrt версии.

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

У меня всё работало без каких-либо плясок с бубном…

дык и у меня когда-то (весьма давненько правда) работало..

ну никак не ожидал такой затыки

всё страньше и страньше: ucrt vs wincrt ситуации не изменяет. даже более того - с gtk-3 ровно такая-же ерунда.

удалось лоцировать до «точка входа в FT_Get_Transform не найдена в бла-бла-бла/libharfbuzz-0.dll» ; то есть что-то про шрифты не хватило..

PS/ конечно после такого брать gtk на любой проект страшно, уже чисто принципиальный вопрос - какого лешего всё так

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от Dr64h

P. S. Только после этого я понял, какое же это дно собирать что-то на Windows, выходя за рамки Visual Studio.

Qt SDK с MinGW (старый, офлайновый) вполне себе самодостаточен под виндой. Да и «конструктором» (подключить другие версии Qt и компилятора) собирается на раз-два.

hobbit ★★★★★
()
Ответ на: комментарий от MKuznetsov

уже чисто принципиальный вопрос - какого лешего всё так

Как-бы авторы не скрывали, что тулкит делают в первую очередь для онтопика и только уже потом, по остаточному принципу, под остальное.

Ну и да, у GTK целая куча зависимостей, что тоже сборку не упрощает, мягко говоря.

«точка входа в FT_Get_Transform не найдена в бла-бла-бла/libharfbuzz-0.dll»

Harfbuzz и freetype точно не старые? FT_Get_Transform появился во freetype очень недавно (коммит) и, следовательно, FreeType >=2.11.1

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

Harfbuzz и freetype точно не старые? FT_Get_Transform появился во freetype очень недавно (коммит) и, следовательно, FreeType >=2.11.1

точно всё новое..для чистоты - mingw64 взят максимально новый

mingw-w64-ucrt-x86_64-freetype 2.12.1-1
mingw-w64-x86_64-freetype 2.12.1-1
mingw-w64-ucrt-x86_64-harfbuzz 5.3.1-2
mingw-w64-x86_64-harfbuzz 5.3.1-2

путём неочевидных манипуляций (с ключиком -mwindows который по идее только про консоль и WinMain) удалось запустить hello_word, который с g_application_run.

Но с gtk_init() подобный фокус не удался.. где-то в недрах gtk_application_init(), g_application_run() очевидно производится правильная инициализация, не освещённая в документации :-(

но мне нужна именно отдельно инициализация и внешний event-loop..

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от hobbit

Qt SDK с MinGW (старый, офлайновый) вполне себе самодостаточен под виндой. Да и «конструктором» (подключить другие версии Qt и компилятора) собирается на раз-два.

То есть старый SDK может подгружать новые версии тулз? Старый это какой, 4 версии?

Dr64h ★★★
()
Ответ на: комментарий от Dr64h

Я Qt Creatorом 3.2.1 (кажется) под виндой подгружал самосборный статический Qt 5.10 (и скачанный бинарный, по-моему, тоже).

hobbit ★★★★★
()
Ответ на: комментарий от Dr64h

То есть старый SDK может подгружать новые версии тулз? Старый это какой, 4 версии?

Да, старый SDK может работать с новым Qt creator и с новыми компиляторами потому что libstdc++ имеет стабильный ABI.

Как-то так работает https://imgur.com/a/0mZvdXe

И это я ничего не собирал, а лишь выбрал из Qt installer. Там последняя версия 32 битного компилятора 8.1, а 64 битного 11.2

Если собирать самостоятельно, то можно использовать и ещё новее компилятор.

fsb4000 ★★★★★
()
Ответ на: комментарий от MKuznetsov

ещё раз, по буквам - всё штатное

Не хотите показывать артефакты, как хотите, нам же меньше работы… 🙄

точка входа в FT_Get_Transform не найдена в бла-бла-бла/libharfbuzz-0.dll

«бла-бла-бла»? 🤔 Положите правильную версию harfbuzz рядом с бинарником, соответствующую той lib-е, которую ликновали при сборке проекта. Не может быть что-бы в SDK были либы одной версии, а библиотеки другой.

Такое ощущение, что у вас там винегрет из библиотек или лишние пути поиска, например, бесконтрольно набитый путями %PATH%.

raspopov
()

до смешного: всё само собой разрулилось и все гипотезы и предположения оказались ложными :-)

в ночи прилетел большой апдейт, после которого всё заработало. Обновился gcc ldd и ещё кучка (over 100) для всех тулчайнов..видимо пост-исправления в свете «2022-10-29 - Changing the default environment from MINGW64 to UCRT64» (https://www.msys2.org/news/).

то есть «ложечки нашлись, но осадочек остался». Всем спасибо, все свободны :-)

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

Да бывает, я помню у меня что-то тоже не собиралось, а собралось только на следующий день, видимо после перезагрузки компьютера.

Dr64h ★★★
()

чтобы два раза не вставать и не заводить лишнюю тему: существует-ли функция обратная к gtk_init() ? провести полную де-инициализацию и освободить все ресурсы ?? без exit()

просто пытался пускать gtk как плагин к уже существующему приложению - то есть и загрузка и выгрузка. Даже хуже того - это может быть одновременно в разных тредах и в одном и том-же повторно :-(

Tk (тот который tcl/tk) так работать умеет, очень хочется такой-же фокус с Gtk или Qt ; в плане gui они слегка получше будут

MKuznetsov ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

удалось лоцировать до «точка входа в FT_Get_Transform не найдена в бла-бла-бла/libharfbuzz-0.dll» ; то есть что-то про шрифты не хватило..

PS/ конечно после такого брать gtk на любой проект страшно, уже чисто принципиальный вопрос - какого лешего всё так

Похоже на то, что сопровождающие msys2 не заморачиваются как в Debian с контролем версий и ABI-совместимости. Если pacman вообще это позволяет. Как раз несколько недель назад накопилось много пакетов для обновления. А нужно было один по-быстренькому. Запустил - не работает. В Debian в подобном случае получил бы предупреждение, что вот это одно обновление требует минимум обновление ещё каких-то пакетов. Если не соглашусь - то вообще не будет обновления, т.к. бессмысленно. Т.е. это, очевидно, не проблема GTK.

gag ★★★★★
()
Ответ на: комментарий от MKuznetsov

чтобы два раза не вставать и не заводить лишнюю тему: существует-ли функция обратная к gtk_init() ? провести полную де-инициализацию и освободить все ресурсы ?? без exit()

GTK можно было бы выгрузить, но GLib нельзя: он статически выделяет ресурсы на систему типов и ещё чего-то, а соответственно и GTK в итоге тоже.

просто пытался пускать gtk как плагин к уже существующему приложению - то есть и загрузка и выгрузка.

Это решается одной единственной статической переменной is_plugin_loaded. Т.е. не производить выгрузку, а повторную загрузку игнорировать.

Даже хуже того - это может быть одновременно в разных тредах и в одном и том-же повторно :-(

Хитро как.

gag ★★★★★
()
Ответ на: комментарий от gag

Это решается одной единственной статической переменной is_plugin_loaded. Т.е. не производить выгрузку, а повторную загрузку игнорировать.

Я так с Tk поступал - там всё как часы. При загрузке если статический флажок=0, то установить в 1 и исполнить глобальный init.

А вот с GTK (или glib) это не прокатывает. При завершении треда, в котором был загружен плагин (инициализован glib/gtk) раздаётся крр..ба-бах..

Tk в этом плане «впереди планеты всей» (gtk/qt) - может независимо одновременно работать в разных тредах и даже(!) несколько экземпляров в одном. Можно завершить gui, можно рестартовать. Чуть пошире-бы ему графические возможности и совсем хорошо.

MKuznetsov ★★★★★
() автор топика
19 апреля 2024 г.
Ответ на: комментарий от MKuznetsov

Tk в этом плане «впереди планеты всей» (gtk/qt) - может независимо одновременно работать в разных тредах

Кстати, недавно пришлось переходить со встраиваемого питона 2 на 3, и gtk2 через python-gi отказался там работать как раньше через старый pygtk (основная программа на gtk2). В связи с этим нагуглилось интересненькое:

The other possibility is that you mean two separate main loops running in two separate threads. This isn’t possible currently. (In retrospect, this was one of the things I should have done differently in the GLib main loop design).

https://mail.gnome.org/archives/gtk-list/1999-September/msg00157.html

Вернули бы Оуэна Тэйлора в разработку glib/gtk.

gag ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.