Remove Windows pkg-config hack from -sys build.rs #631

sdroege · 2018-08-29T06:11:17Z

We can simply use pkg-config to list us all required shared libraries
instead of only taking the library paths.

pkg-config-rs works properly on MSVC and MinGW now

We can simply use pkg-config to list us all required shared libraries instead of only taking the library paths.

sdroege · 2018-08-29T06:30:21Z

The way how it fails on AppVeyour now is caused by a misconfigured environment. Those Windows libraries must be in the library path so that the linker can actually find them as needed.

@EPashkin You run Windows, right? Can you check what's wrong there?

https://ci.appveyor.com/project/GuillaumeGomez/gir/build/1.0.1182/job/l7ifw9e6l4fpsi9i

EPashkin · 2018-08-29T16:31:30Z

@sdroege Have same error, investigating.

EPashkin · 2018-08-29T18:07:41Z

src/codegen/sys/build.rs

-                for path in library.link_paths.iter() {
-                    println!("cargo:rustc-link-search=native={}",
-                             path.to_str().expect("library path doesn't exist"));
-                }


For me only this for can be removed even after upgrading pkg-config to 0.3.14, but not sure that it works globally as I have msys64/bin with gtk's dlls in path.
I tested on examples\cairo_threads.rs, do this change works fine for cairo-sys.
But on gtk it not works:
removing dylib caused many

D:\eap\rust\0\target\debug\deps\libgtk-d3ee1e1d9d9104f6.rlib(gtk-d3ee1e1d9d9104f6.1consvywiv34sg52.rcgu.o): In function `_$LT$gtk..border..MemoryManager$u20$as$u20$glib..boxed..BoxedMemoryManager$LT$gtk_sys..GtkBorder$GT$$GT$::free::h324bcaf1ec9c7496': D:/eap/rust/0/gtk\src/border.rs:20: undefined reference to `gtk_border_free'

removing config.cargo_metadata(false); caused

= note: ld: cannot find -limm32 ld: cannot find -ldwmapi ld: cannot find -lcfgmgr32

Any idea why? Can you provide the corresponding (for each issue) cargo output (with -vv) of a clean build?

IMHO at minimum no working gtk static lib on windows, about others I don't have any idea.
Output here: https://gist.github.com/EPashkin/a07f84a48f1b791e382e22716e2da144

Why would it try static libs to begin with?

The GTK undefined symbols happen because there's no -lgtk-3 in the linker commandline. The gtk-sys build.rs does not output this (or anything) for whatever reason. Can you check why? The other -sys crates output the correct things.

The missing Windows libraries, can you check where they are on your system and why those directories (the ones with the correspnding .lib files) are not in the linker search path?

EPashkin · 2018-08-30T08:07:06Z

Continue talk from #631 (comment)
There no cargo:rustc-link-lib=gtk-3 in _no_dylib.txt as it has config.cargo_metadata(false);.
In _no_dylib_metadata.txt it present without dylib,
libgtk-3.dll.a also present in location by "-L" "D:/P/msys64/mingw64/lib"
and it don't contains string imm32, dwmapi, cfgmgr32

sdroege · 2018-08-30T08:31:12Z

Ok, the cargo metadata is needed for proper functioning so let's ignore that case.

So the only actual problem is that the imm32, etc libraries are not found, correct? Where are they (and their corresponding .lib files) on your system and are they part of the linker search path?

EPashkin · 2018-08-30T09:08:19Z

All 3 of those libraries is 32bit (only on 64bit system) and lies in different lib folder.
If I manually add println!("cargo:rustc-link-search=native=D:/P/msys64/mingw64/x86_64-w64-mingw32/lib"); to gtk-sys's build-rs, then it builds and works too.
Not sure what to do with this.

sdroege · 2018-08-30T09:50:51Z

rustc should've added that path to the linker path already (when using the mingw toolchain)

EPashkin · 2018-08-30T11:03:20Z

This path not from rust installation, but from separate msys2x64, so rustc can't add it.
Set "LIBRARY_PATH" environment to "D:/P/msys64/mingw64/x86_64-w64-mingw32/lib"
helps me locally, but with it we need set it for all appveyor.yml on x64 build.
Long term solution is fix pgkconfix's gtk+-3.0.pc for msys2x64, but it will take time even if accepted

sdroege · 2018-08-30T11:39:10Z

It's wrong that those libraries are in the .pc file actually... if they are not needed for linking they should not be there.

EPashkin · 2018-08-30T11:53:49Z

Libraries not in .pc file, it also not in libgtk-3.dll.a as I can see (tried find strings),
but libgtk-3-0.dll depends on them

prefix=/mingw64
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
targets=win32 broadway

gtk_binary_version=3.0.0
gtk_host=x86_64-w64-mingw32

Name: GTK+
Description: GTK+ Graphical UI Library
Version: 3.22.30
Requires: gdk-3.0 atk >= 2.15.1 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gdk-pixbuf-2.0 >= 2.30.0 gio-2.0 >= 2.49.4
Requires.private: atk   epoxy >= 1.0
Libs: -L${libdir} -lgtk-3 
Cflags: -I${includedir}/gtk-3.0 -mms-bitfields

EPashkin · 2018-08-30T12:05:59Z

But pkg-config get it from somewhere

> pkg-config --libs gtk+-3.0
-LD:/P/msys64/mingw64/lib -lgtk-3 -lgdk-3 -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lz -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

EPashkin · 2018-08-30T12:06:59Z

Also strange for 32bit mode:
It don't builds without LIBRARY_PATH with same error,
but builds with it even it links to 32 for 64 proxy, but failed to run.
Msys2x64 for it don't have separate libimm32.a for 32bit.

sdroege · 2018-08-30T15:26:54Z

But pkg-config get it from somewhere

grep for them in all pkg-config files you have. It's probably from GDK or PangoWin32

sdroege · 2018-08-30T15:28:21Z

In any case, the problem here are a) broken pkg-config files (they should not include those libraries unless their API is used from any headers, they should only be in Libs.private here) and b) those libraries not in the correct places or environment variables not set correctly for GTK.

It's not a problem of pkg-config

EPashkin · 2018-08-30T17:02:23Z

Yes, all 3 dlls present in gdk-3.0.pc, gdk-broadway-3.0.pc, gdk-win32-3.0.pc,
all 3 identifical:

prefix=/mingw64
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
targets=win32 broadway

Name: GDK
Description: GTK+ Drawing Kit
Version: 3.22.30
Requires: pangowin32 pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0
Requires.private: gio-2.0 >= 2.49.4     cairo-win32 cairo epoxy >= 1.0 
Libs: -L${libdir} -lgdk-3  -lgdi32 -limm32 -lshell32 -lole32 -Wl,-luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lz
Cflags: -I${includedir}/gtk-3.0

sdroege · 2018-08-30T17:05:47Z

Ok, so what I said above then :) GDK and environment setup bug

EPashkin · 2018-09-01T15:04:36Z

@sdroege This seems can be closed too.
Bad that it not works.

sdroege · 2018-09-01T17:03:29Z

Because of bugs elsewhere, yes. We should report those at least :)

@nirbheek do you have any input here?

nirbheek · 2018-09-03T03:24:53Z

println!("cargo:rustc-link-search=native=D:/P/msys64/mingw64/x86_64-w64-mingw32/lib"); to gtk-sys's build-rs, then it builds and works too.
Not sure what to do with this.

This is strange, you should not need to specify the toolchain library path for linking. The compiler has those paths hard-coded. Run: gcc --print-search-dirs to see the full list.

I just checked, and MSYS2 MinGW64 does not need anything extra to find those base libraries -limm32, etc.

EPashkin · 2018-09-03T04:41:01Z

Seems problem with rust version of gcc, there output for it (I added line endings for libs)

C:\Documents and Settings\eap\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\gcc.exe --print-search-dirs

install: C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/
programs: =C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0/;C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../libexec/gcc/;C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/6.3.0/;C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/bin/
libraries: =C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/6.3.0/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/lib/../lib/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../x86_64-w64-mingw32/6.3.0/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../lib/;
C:/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/mingw/lib/x86_64-w64-mingw32/6.3.0/;
C:/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/mingw/lib/../lib/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/lib/;
C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../;
C:/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/mingw/lib/

I have no subfolders in C:/Documents and Settings/eap/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/ so all of these path not exists
Also there has never existed C:/mingw630

nirbheek · 2018-09-03T04:49:05Z

Those paths seem to be completely broken. When configured correctly, gcc sets those paths relative to its current location, so you can move the toolchain directory and the dirs will still be correct.

sdroege · 2018-09-03T07:02:03Z

This sounds like it (also) needs a bug reports against the Rust MinGW toolchain then: for what @nirbheek said as well as for not including the MinGW .libs for the system libraries

EPashkin · 2018-09-04T09:16:21Z

Note: despite warning near rust gcc.exe it not done its primary task: if I build program until I get link error and then rename this gcc.exe link (only step that last) will work fine with msys2x64 gcc

gcc.exe contained in this folder cannot be used for compiling C files - it is onlyused as a linker. In order to be able to compile projects containing C code usethe GCC provided by MinGW or Cygwin.

sdroege · 2020-11-06T19:35:24Z

Happened in the meantime

Remove Windows pkg-config hack from -sys build.rs

ca08e61

We can simply use pkg-config to list us all required shared libraries instead of only taking the library paths.

sdroege force-pushed the no-windows-pkgconfig-hack branch from aeee423 to ca08e61 Compare August 29, 2018 06:29

EPashkin reviewed Aug 29, 2018

View reviewed changes

EPashkin added a commit to EPashkin/rust-gnome-sys that referenced this pull request Aug 30, 2018

Regen with gtk-rs/gir#631

e402d92

sdroege mentioned this pull request Sep 17, 2018

Cross-compilation (host x86_64 linux - target aarch64 linux) sdroege/gstreamer-rs#130

Closed

sdroege closed this Nov 6, 2020

sdroege deleted the no-windows-pkgconfig-hack branch November 6, 2020 19:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove Windows pkg-config hack from -sys build.rs #631

Remove Windows pkg-config hack from -sys build.rs #631

sdroege commented Aug 29, 2018

sdroege commented Aug 29, 2018 •

edited

Loading

EPashkin commented Aug 29, 2018

EPashkin Aug 29, 2018

sdroege Aug 30, 2018

EPashkin Aug 30, 2018

sdroege Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

EPashkin commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Sep 1, 2018

sdroege commented Sep 1, 2018

nirbheek commented Sep 3, 2018

EPashkin commented Sep 3, 2018 •

edited

Loading

nirbheek commented Sep 3, 2018

sdroege commented Sep 3, 2018

EPashkin commented Sep 4, 2018

sdroege commented Nov 6, 2020

Remove Windows pkg-config hack from -sys build.rs #631

Remove Windows pkg-config hack from -sys build.rs #631

Conversation

sdroege commented Aug 29, 2018

sdroege commented Aug 29, 2018 • edited Loading

EPashkin commented Aug 29, 2018

EPashkin Aug 29, 2018

Choose a reason for hiding this comment

sdroege Aug 30, 2018

Choose a reason for hiding this comment

EPashkin Aug 30, 2018

Choose a reason for hiding this comment

sdroege Aug 30, 2018

Choose a reason for hiding this comment

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

EPashkin commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Aug 30, 2018

sdroege commented Aug 30, 2018

EPashkin commented Sep 1, 2018

sdroege commented Sep 1, 2018

nirbheek commented Sep 3, 2018

EPashkin commented Sep 3, 2018 • edited Loading

nirbheek commented Sep 3, 2018

sdroege commented Sep 3, 2018

EPashkin commented Sep 4, 2018

sdroege commented Nov 6, 2020

sdroege commented Aug 29, 2018 •

edited

Loading

EPashkin commented Sep 3, 2018 •

edited

Loading