An error occurred during compilation: LINK: fatal error LNK1181
Hyijun opened this issue · comments
When I use the code on the example and try to run cargo build , I get this error, suggesting that link.exe cannot open the file gtk-3.lib.
this is my code:
extern crate gtk;
use gtk::prelude::*;
use gio::prelude::*;
use gtk::{Application, ApplicationWindow, Button};
fn main() {
let application = Application::new(
Some("com.github.gtk-rs.examples.basic"),
Default::default(),
).expect("failed to initialize GTK application");
application.connect_activate(|app| {
let window = ApplicationWindow::new(app);
window.set_title("First GTK+ Program");
window.set_default_size(350, 70);
let button = Button::new_with_label("Click me!");
button.connect_clicked(|_| {
println!("Clicked!");
});
window.add(&button);
window.show_all();
});
application.run(&[]);
}
this is some pieces of infomation that Cargo shows
= note: Non-UTF-8 output: LINK : fatal error LNK1181: \xce\xde\xb7\xa8\xb4\xf2\xbf\xaa\xca\xe4\xc8\xeb\xce\xc4\xbc\xfe\xa1\xb0gtk-3.lib\xa1\xb1\r\n
Caused by:
process didn't exit successfully: `rustc --crate-name gui_test --edition=2018 src\main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=a541fdb958e22d7e --out-dir J:\rust\gui_test\target\debug\deps -C inc
remental=J:\rust\gui_test\target\debug\incremental -L dependency=J:\rust\gui_test\target\debug\deps --extern gio=J:\rust\gui_test\target\debug\deps\libgio-184bc09ad01ede68.rlib --extern gtk=J:\rust\gui_test\target\debug\deps\libgtk-95b79b9f549ef0ba.rlib` (exit code: 1)
Could you please help me to slove this problem?
Did you install GTK before you tried this, if so how?
Yes, I have already installed GTK before I try to complete project. I installed GTK in Msys2, and add some key paths to environment variables. Maybe it's because I installed it the wrong way?
Maybe, what does pkg-config --libs gtk+-3.0 show?
Msys2 terminal shows:
-LD:/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl
And does D:/msys64/mingw64/lib contain gtk-3.lib?
No. Just some files with suffix .a .
And the structure of directory gtk-3.0 is like this, the last directory is empty:
lib\gtk-3.0\3.0.0\immodules
All files and directories in lib/
$ ls
bfd-plugins libfreetype.dll.a liblzma.a libsqlite3.dll.a
binutils libfribidi.a liblzma.dll.a libssl.a
cmake libfribidi.dll.a liblzo2.a libssl.dll.a
dde1.4 libgailutil-3.dll.a liblzo2.dll.a libsystre.a
engines-1_1 libgdk-3.dll.a libmangle.a libsystre.dll.a
gcc libgdk_pixbuf-2.0.dll.a libmenuw.a libtasn1.a
gdk-pixbuf-2.0 libgettextlib.a libmenuw_g.a libtasn1.dll.a
gettext libgettextlib.dll.a libmpc.a libtcl.dll.a
girepository-1.0 libgettextpo.a libmpdec.a libtcl86.dll.a
glib-2.0 libgettextpo.dll.a libmpdec.dll.a libtclstub86.a
gtk-3.0 libgettextsrc.dll.a libmpfr.a libtermcap.a
itcl4.2.0 libgio-2.0.a libncurses++w.a libtermcap.dll.a
libasprintf.a libgio-2.0.dll.a libncurses++w_g.a libthai.a
libasprintf.dll.a libglib-2.0.a libncurses.a libthai.dll.a
libatk-1.0.a libglib-2.0.dll.a libncursesw.a libtiff.a
libatk-1.0.dll.a libgmodule-2.0.a libncursesw_g.a libtiff.dll.a
libbrotlicommon-static.a libgmodule-2.0.dll.a libp11-kit.dll.a libtiffxx.a
libbrotlicommon.dll.a libgmp.a libpanelw.a libtiffxx.dll.a
libbrotlidec-static.a libgmp.dll.a libpanelw_g.a libtk.dll.a
libbrotlidec.dll.a libgmpxx.a libpango-1.0.a libtk86.dll.a
libbrotlienc-static.a libgmpxx.dll.a libpango-1.0.dll.a libtkstub86.a
libbrotlienc.dll.a libgnumake-1.dll.a libpangocairo-1.0.a libtre.a
libbz2.a libgnurx.a libpangocairo-1.0.dll.a libtre.dll.a
libbz2.dll.a libgnurx.dll.a libpangoft2-1.0.a libturbojpeg.a
libcairo-gobject.a libgobject-2.0.a libpangoft2-1.0.dll.a libturbojpeg.dll.a
libcairo-gobject.dll.a libgobject-2.0.dll.a libpangowin32-1.0.a libxml2.a
libcairo-script-interpreter.a libgraphite2.a libpangowin32-1.0.dll.a libxml2.dll.a
libcairo-script-interpreter.dll.a libgraphite2.dll.a libpcre.a libxxhash.dll.a
libcairo.a libgthread-2.0.a libpcre.dll.a libz.a
libcairo.dll.a libgthread-2.0.dll.a libpcre16.a libz.dll.a
libcharset.a libgtk-3.dll.a libpcre16.dll.a libzstd.a
libcharset.dll.a libharfbuzz-gobject.a libpcre32.a libzstd.dll.a
libcrypto.a libharfbuzz-gobject.dll.a libpcre32.dll.a p11-kit
libcrypto.dll.a libharfbuzz-icu.a libpcrecpp.a pkcs11
libdatrie.a libharfbuzz-icu.dll.a libpcrecpp.dll.a pkgconfig
libdatrie.dll.a libharfbuzz-subset.a libpcreposix.a python3.8
libedit.dll.a libharfbuzz-subset.dll.a libpcreposix.dll.a reg1.3
libedit_static.a libharfbuzz.a libpixman-1.a sqlite3.30.1.2
libepoxy.a libharfbuzz.dll.a libpixman-1.dll.a sqlite3.32.2
libepoxy.dll.a libhistory.a libpng.a tcl8
libexpat.a libhistory.dll.a libpng.dll.a tcl8.6
libexpat.dll.a libiconv.a libpng16.a tclConfig.sh
libffi.a libiconv.dll.a libpng16.dll.a tdbc1.1.1
libffi.dll.a libintl.a libpython3.8.dll.a tdbcmysql1.1.1
libfontconfig.a libintl.dll.a libreadline.a tdbcodbc1.1.1
libfontconfig.dll.a libisl.a libreadline.dll.a tdbcpostgres1.1.1
libformw.a libjasper.a libregex.a terminfo
libformw_g.a libjasper.dll.a libregex.dll.a thread2.8.5
libfreeglut.dll.a libjpeg.a librsvg-2.a tk8.6
libfreeglut_static.a libjpeg.dll.a librsvg-2.dll.a tkConfig.sh
libfreetype.a libjson-glib-1.0.dll.a libsqlite3.a xml2Conf.sh
Are you using the MSVC or MINGW Rust toolchain? I think you need to use the latter for making use of the msys libraries, but I'm not entirely sure.
This looks in any case like an msys problem, it should really generate .lib files for the things it's installing.
It works fine with just lib/libgtk-3.dll.a and bin/libgtk-3-0.dll for me
But only with the MINGW toolchain, not the MSVC one?
yes
for MVSC IMHO lib need generated with MS 'dllimport' (I do not remember utility name)
With lib.exe from MSVC. dlltool (GNU binutils) can also be used for it but it often generates corrupted import libraries unfortunately...
If msys2 would somehow make sure to include .lib files, both toolchains would work.
I had a problem similar to this one. I resolved it by executing these two commands:
`rustup toolchain add stable-x86_64-pc-windows-gnu
rustup default stable-x86_64-pc-windows-gnu`