#rust #gtk #rust-cargo #meson-build #gtk-rs
Вопрос:
У меня есть базовый проект gtk-rs, в котором я использую meson. Я включил ящик gtk4 в файл Cargo.toml. Когда я запускаю с грузом, он компилируется, но выдает ошибку «ошибка сегментации» (я искал и до сих пор не знаю, что это такое). Однако, когда я запускаю meson, он вообще отказывается строиться.
builddir/
main.p/
build.ninja
src/
main.rs
target/
...
Cargo.toml
Cargo.lock
meson.build
Груз.томл
[package]
name = "my-gtk-app"
version = "0.1.0"
edition = "2018"
[dependencies]
gtk = { version = "0.2", package = "gtk4" }
мезон.сборка
project(
'my-gtk-app',
'rust',
version : '0.1',
)
cargo_sources = files(
'Cargo.toml',
'Cargo.lock',
)
gtk = dependency('gtk4', version: '>= 4.0.0')
executable('main', 'src/main.rs', dependencies : gtk)
main.rs
use gtk::prelude::*;
use gtk::{Application, ApplicationWindow};
fn main() {
let app = Application::builder()
.application_id("org.example.HelloWorld")
.build();
app.connect_activate(|app| {
// We create the main window.
let window = ApplicationWindow::builder()
.application(app)
.default_width(320)
.default_height(200)
.title("Hello, World!")
.build();
// Show the window.
window.show();
});
app.run();
}
Когда я запускаю программу с помощью cargo run
, я получаю
Finished dev [unoptimized debuginfo] target(s) in 0.45s
Running `target/debug/my-gtk-app`
1] 73039 segmentation fault cargo run
Однако, когда я бегаю с с meson compile -C builddir
, я получаю
ninja: Entering directory `builddir'
[1/1] Compiling Rust source ../src/main.rs
FAILED: main
rustc -C linker=cc --color=always --crate-type bin --crate-name main -g --emit dep-info=main.d --emit link -o main -L/usr/local/Cellar/gtk4/4.4.0/lib -L/usr/local/Cellar/pango/1.48.10/lib -L/usr/local/Cellar/harfbuzz/3.0.0/lib -L/usr/local/Cellar/gdk-pixbuf/2.42.6/lib -L/usr/local/Cellar/cairo/1.16.0_5/lib -L/usr/local/Cellar/graphene/1.10.6/lib -L/usr/local/Cellar/glib/2.70.0_1/lib -L/usr/local/opt/gettext/lib -l dylib=gtk-4 -l dylib=pangocairo-1.0 -l dylib=pango-1.0 -l dylib=harfbuzz -l dylib=gdk_pixbuf-2.0 -l dylib=cairo-gobject -l dylib=cairo -l dylib=graphene-1.0 -l dylib=gio-2.0 -l dylib=gobject-2.0 -l dylib=glib-2.0 -l dylib=intl ../src/main.rs
error[E0433]: failed to resolve: maybe a missing crate `gtk`?
--> ../src/main.rs:1:5
|
1 | use gtk::prelude::*;
| ^^^ maybe a missing crate `gtk`?
error[E0432]: unresolved import `gtk`
--> ../src/main.rs:2:5
|
2 | use gtk::{Application, ApplicationWindow};
| ^^^ maybe a missing crate `gtk`?
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
ninja: build stopped: subcommand failed.
Я на macOS, если это поможет.
Комментарии:
1. Похоже
meson
, что это вызовrustc
(неcargo
) и игнорирование вашейCargo.toml
(или, по крайней мере, информации о ее зависимости). Я не знаю, какmeson
это работает, поэтому не могу сказать, как это исправить.2. Я открыт для использования любой другой альтернативы. это всего лишь официальная книга, подтвержденная gtk-rs ( gtk-rs.org/gtk4-rs/stable/latest/book/hello_world ) рекомендует это. У вас есть другие на примете?
3. Ваша установка сильно отличается от
gtk-rust-template
проекта, к которому вас направляет эта книга? В частности, я имею в виду ваш корневойmeson.build
файл, сценарии вbuild-aux
папке, от которой он зависит, иmeson.build
файлы в подкаталогах, которые он извлекает (данные, po и src):src/meson.build
вызывает cargo какcustom_target
то, что было определено в корневом файле. Есть ли какая-то причина, по которой вы не начали с шаблона, как рекомендовано в книге?4. Спасибо вам за ваш комментарий. Это было первое, что я сделал. Однако я могу использовать скрипт python только для инициализации проекта. Я не могу использовать flatpac, потому что я не на Linux.
5. Мезон не использует груз по дизайну (это было бы похоже на то, как мезон вызывает cmake или ./configure). В какой-то момент в meson.build была ветка для обработки ящиков (я автор этой серии), но она так и не приземлилась. Использование Мезона с ржавчиной прямо сейчас действительно хорошо работает только для проектов, которые не используют ящики, поскольку основными потребителями этой функции являются проекты C/C с низким уровнем в стеке, которые занимаются ржавчиной, которые не могут или не будут использовать ящики.