Сборка и запуск приложения GTK в Windows с помощью Meson - PullRequest
Новая
       42

Сборка и запуск приложения GTK в Windows с помощью Meson

0 голосов
/ 13 марта 2019

В настоящее время я не могу успешно запустить приложение, которое я успешно создал с помощью Meson.Чтобы установить GTK, я выполнил шаги, доступные здесь , чтобы установить его.Кроме того, я добавил путь C:\msys64\mingw64\bin к своему пути.

Внутри этого пути я смог успешно запустить приложения gtk-demo.exe, gtk3-demo.exe и gtk3-demo-application.exe, которые указывали бы, что он установленуспешно.

Я намеревался создать пример приложения, представленного в учебнике для Meson: 

#include<gtk/gtk.h>

int main(int argc, char **argv) {
  GtkWidget *win;
  gtk_init(&argc, &argv);
  win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(win), "Hello there");
  g_signal_connect(win, "destroy", G_CALLBACK(gtk_main_quit), NULL);
  gtk_widget_show(win);
  gtk_main();
}

Запуск ninja в моем builddir Я получаю следующий вывод: 

[1/1] Linking target test.exe.
LINK : warning LNK4044: unrecognized option '/-no-undefined'; ignored
LINK : warning LNK4044: unrecognized option '/-as-needed'; ignored
LINK : warning LNK4044: unrecognized option '/-start-group'; ignored
LINK : warning LNK4044: unrecognized option '/luuid'; ignored
LINK : warning LNK4044: unrecognized option '/-end-group'; ignored

Однако, запустив его, я сталкиваюсь со следующей ошибкой:

Не удалось найти точку входа в процедуру g_application_get_type в библиотеке динамических ссылок C: \ Users \ me \ proj \builddir \ test.exe.

Понимая, что это проблема, вызванная попаданием в ад DLL, я проверил свой путь (отлично) и скопировал все библиотеки gtk, которые я мог найти в каталоге bin, вместный builddir.Это тоже не сработало.

Я в растерянности - я просто хотел бы заставить это работать!Что я должен попытаться сделать, чтобы это исправить?

1 Ответ

0 голосов
/ 14 марта 2019

По общему признанию, это была очень трудная проблема, и спросить ее таким образом, чтобы получить ответ, было еще труднее.

После нескольких дней выдергивания оставшихся у меня волосков я удалил builddir переместил двоичный путь mingw64 выше в моей среде и начал его перестраивать.

Как оказалось, это похоже на проблему с бэкэндом clang, использующим ниндзя.Переключение серверной части на gcc (благодаря перемещению папки mingw64/bin вверх) волшебным образом решило проблему, несмотря на то, что я ничего не удалял из переменных среды.

Я действительно ненавижу магию - но у меня нет дальнейших объяснений этого или причины, по которой clang потерпит неудачу, а gcc сработает.Если бы кто-то мог ответить улучшенным ответом, это было бы здорово.Я не волшебник компилятора в отношении различных бэкэндов C / C ++.

...