search

gtk-rs / gtk

DEPRECATED, use https://github.com/gtk-rs/gtk3-rs repository instead!
https://gtk-rs.org/
MIT License
1.25k stars 82 forks source link

[windows] GTK application builds but immediately crashes #539

Closed JoeyAcc closed 5 years ago

JoeyAcc commented 7 years ago

I'm trying to get a windows application to work which depends on gtk-rs. After some back and forth compilation works, but as soon as I try to start the generated binary I get this:

Error screenshot

Putting aside the fact that the error is in Dutch (100% of my workstation's software is in English), the error complains about not being able to find some access point named inflateValidate in the DLL C:\msys64\mingw64\bin\libpng16-16.dll.

GuillaumeGomez commented 7 years ago

Wo, funny error! Give a try to dependencywalker software. Maybe it's just a missing DLL?

JoeyAcc commented 7 years ago

Thank you for the quick response. Where may I be able to find dependencywalker?

GuillaumeGomez commented 7 years ago

On google I suppose? It's been a while I didn't use it but it works on windows 10. A small google research should give you access to it.

JoeyAcc commented 7 years ago

Just opened the binary with ``dependencywalker. The output is... less helpful than I had hoped:

Error screenshot

I also ran a find to locate the DLL:

$ find /c/msys64/ -name libpng16-16.dll

/c/msys64/mingw64/bin/libpng16-16.dll

The odd thing about that is that C:\msys64\mingw64\bin is already known by the windows PATH system variable, and thus the binary should be able to find it.

EPashkin commented 7 years ago

May be your libpng too old? In view dll, I find string inflateValidate and __impl__inflateValidate in my version.

#in msys2 command prompt
pacman -Ss libpng
mingw32/mingw-w64-i686-libpng 1.6.30-1 
mingw64/mingw-w64-x86_64-libpng 1.6.30-1
EPashkin commented 7 years ago

Also you can try run your examples https://github.com/gtk-rs/examples/blob/master/src/bin/menu_bar.rs or https://github.com/gtk-rs/examples/blob/master/src/bin/treeview.rs. It both try load png file.

JoeyAcc commented 7 years ago

I've tried treeview, and got the exact same result.

EPashkin commented 7 years ago

Then something wrong with installation, check version in msys2 command prompt. Maybe even do update with pacman -Syu

JoeyAcc commented 7 years ago

Upgrading with pacman -Syu was a good idea, and I tried just that, and rebooted my workstation after. Unfortunately it doesn't make a difference as the error is still present.

EPashkin commented 7 years ago

What says pacman -Ss libpng ? My last idea is reinstall libpng: pacman -S mingw64/mingw-w64-x86_64-libpng

JoeyAcc commented 7 years ago

I just tried both:

joey@DESKTOP-P4V3PIP MSYS ~
$ pacman -Ss libpng
mingw32/mingw-w64-i686-libpng 1.6.30-1
    A collection of routines used to create PNG format graphics (mingw-w64)
mingw64/mingw-w64-x86_64-libpng 1.6.30-1 [installed]
    A collection of routines used to create PNG format graphics (mingw-w64)

joey@DESKTOP-P4V3PIP MSYS ~
$ pacman -S mingw64/mingw-w64-x86_64-libpng
warning: mingw-w64-x86_64-libpng-1.6.30-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) mingw-w64-x86_64-libpng-1.6.30-1

Total Installed Size:  1.59 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                                                                                                                     [####################################################################################################] 100%
(1/1) checking package integrity                                                                                                                                   [####################################################################################################] 100%
(1/1) loading package files                                                                                                                                        [####################################################################################################] 100%
(1/1) checking for file conflicts                                                                                                                                  [####################################################################################################] 100%
(1/1) checking available disk space                                                                                                                                [####################################################################################################] 100%
:: Processing package changes...
(1/1) reinstalling mingw-w64-x86_64-libpng                                                                                                                         [####################################################################################################] 100%

Sadly I still get the same result. I really don't understand the message either, as The DLL C:\msys64\mingw64\bin\libpng16-16.dll exists.

EPashkin commented 7 years ago

This message IMHO says that it can't find entry point "inflateValidate" in DLL. I have no idea why.

GuillaumeGomez commented 7 years ago

You just installed the 1.6.30 version and it complains about the 1.6.16 missing? Strange. :-/

JoeyAcc commented 7 years ago

@EPashkin Indeed, but that would imply that the file is corrupted somehow. And since I just updated it, it would suggest the issue lies with msys2, so I'll open an issue there as well and link back to this one.

@GuillaumeGomez Not quite. It complains about a dll with the (admittedly rather strange) name libpng16-16.dll. That name was not changed by the upgrade.

GuillaumeGomez commented 7 years ago

Then are you sure they're the same file?

JoeyAcc commented 7 years ago

On the one hand there is the error screenshot in the OP, on the other there is this:

joey@DESKTOP-P4V3PIP MSYS ~
$ ls -ahl /c/msys64/mingw64/bin/|grep png
-rwxr-xr-x 1 joey Domain Users 227K Jun 30 07:07 libpng16-16.dll
-rwxr-xr-x 1 joey Domain Users 2.3K Jun 30 07:07 libpng16-config
-rwxr-xr-x 1 joey Domain Users 2.3K Jun 30 07:07 libpng-config
-rwxr-xr-x 1 joey Domain Users  81K Jun 30 07:07 pngfix.exe
-rwxr-xr-x 1 joey Domain Users  22K Jun 30 07:07 png-fix-itxt.exe

If /c/msys64/mingw64/bin/libpng16-16.dll doesn't match C:\msys64\mingw64\bin\libpng16-16.dll then something is really badly broken on a fundamental level somewhere I'd say.

GuillaumeGomez commented 7 years ago

Trying very strongly not to troll windows again.

JoeyAcc commented 7 years ago

You'd be correct in doing so, and I would sympathize. Working with Windows = massive pain.

GuillaumeGomez commented 7 years ago

Everytime I did, it was a real nightmare. But I think it's mostly because I don't master windows much. Maybe we're missing something obvious? Let's keep our minds open just in case. ;)

JoeyAcc commented 7 years ago

It's always possible we're missing something that (in retrospect) is obvious. But at this exact moment I'm fresh out of ideas, which is why I opened an issue @ msys.

mati865 commented 7 years ago

On Windows error about missing libpng16-16.dll library (or symbol like here) in most cases is misleading and means the dependency of libpng16-16.dll is missing.

In this case probably the problem is missing zlib1.dll in runtime libs. Here you can see symbol in MSYS2 mingw-w64-zlib package:

nm /mingw64/lib/libz.dll.a | grep inflateValidate
0000000000000000 I __imp_inflateValidate
0000000000000000 T inflateValidate

It could be bug in a crate your project depends on.

I'll look at it over the weekend.

P.S. libpng16-16.dll is the way upstream named this lib on Windows, on Linux (Ubuntu in this case) it is named libpng16.so.16.28.0 and libpng16.so.16 is symlinked to it.

mati865 commented 7 years ago

This message IMHO says that it can't find entry point "inflateValidate" in DLL. I have no idea why.

Forgot to mention it in previous comment but nm is generally handy in such cases:

nm /mingw64/bin/libpng16-16.dll | grep inflateValidate
0000000068b7c348 I __imp_inflateValidate

It wants to import __imp_inflateValidate from another lib but cannot find it.

mati865 commented 7 years ago

I cannot reproduce it with with treeview using stable and nightly.

oRole commented 6 years ago

Maybe it's too late, maybe not. I faced the same error and solved it through moving the PATH entry 'C:\msys64\mingw32\bin' to a position with higher priority. So try to play around with that if it is not too late at all.

saolof commented 6 years ago

@oRole I'm stuck with the same error myself. Moving the msys64 entry in the path to the highest priority did nothing.

oRole commented 6 years ago

@saolof Additionally I used the dll-files that are contained within ffmpegs' shared package (ffmpeg-download). If the error still exists, I also took another zlib1.dll from the webs. Unfortunately I don't remember which one it was.

mati865 commented 6 years ago

Probably one of zblib dependencies is missing.

ImreMD commented 6 years ago

Hi everybody, I did have this error but what's funny my program (small GTK GUI program):

`import Graphics.UI.Gtk import Control.Monad.Trans.Reader import Control.Monad.IO.Class

main = do initGUI window <- windowNew window on deleteEvent $ liftIO mainQuit >> return False widgetShowAll window mainGUI`

runs without crashing in the ghc shell (stack runghc Main.hs in my project app folder and the window pops) ... So for me the solution is somewhere at hand but need to find how may be copy + paste the zlib.dll used by the shell to the library folder used for compilation by stack...? I started I discussion here: https://github.com/commercialhaskell/stack/issues/3810

GuillaumeGomez commented 6 years ago

It doesn't look like rust language at all...

ImreMD commented 6 years ago

Uuups you're right I didn't pay attention.... I had trouble with haskell/stack sorry ... may be it's better to delete my comment. best regards

Hraesvel commented 6 years ago

Windows 10 user here I can't run the executable directly from Cmd/Powershell, it did, however, work when I executed it from the mingw64 shell.

Are these supposedly meant to compile into portable executables? or msys2 is required to be installed in order to run?

EPashkin commented 6 years ago

@Ostoyae you build program from mingw64 shell or from cmd? It possible that you don't have some msys2 libs in %PATH% or near program. As test you can copy program executable to "%msys_root%\mingw64\bin\" and try run from here.

Hraesvel commented 6 years ago

@EPashkin Thanks for getting back, I used the cmd to build the examples. Also did what was required based on this post: http://gtk-rs.org/docs/requirements.html Unless it's missing something crucial?

EPashkin commented 6 years ago

@Ostoyae sorry for long delay for reply. Only that I can propose is:

As test you can copy program executable to "%msys_root%\mingw64\bin" and try run from here.

If it work, then you need check PATH environment variable or use http://www.dependencywalker.com/ to check which dll missing or maybe used from other msys installs

psycha0s commented 5 years ago

I had the same issue with msys2 and Qt. It turned out that there was another version of zlib1.dll in PATH. In my case I found it in C:\Windows\System32\zlib1.dll. I know this is an old discussion but there is a chance it'll help somebody.

aQaTL commented 5 years ago

Thanks @phantom-code. In my case, I found zlib1.dll in my PostgreSQL installation.

sdroege commented 5 years ago

Let's close this then? These crashes seem to be a normal case of Windows DLL hell and a setup problem, nothing we can influence here.

@GuillaumeGomez ?

saolof commented 5 years ago

I disagree, it is something that could be addressed with better cargo packaging.

Using linked system binaries is a terrible default setting, since you'll pretty much always want to bundle the GTK binaries with your application when you do your final deployment anyway, and it isn't particularly useful for prototyping either (system binaries save you a few MB on project folder size?). On the other hand, it makes it outright impossible to get started with GUI's for a significant fraction of Rust developers.

By contrast, GTK bindings for some other languages with a package manager such as Julia, allow you to get started with just a Pkg> install Gtk which just works out of the box for users on all major platforms.

sdroege commented 5 years ago

I disagree, it is something that could be addressed with better cargo packaging.

See https://github.com/gtk-rs/gtk/pull/753 and https://github.com/gtk-rs/gtk/issues/702

These need someone to look at all the constraints and implement a reasonable solution, maybe similar to what e.g. is done in Julia as you mention.

Using linked system binaries is a terrible default setting, since you'll pretty much always want to bundle the GTK binaries with your application when you do your final deployment anyway

That's true and it means that you somehow need to have control over where the GTK/etc binaries come from so that you can actually bundle them with your application. You don't really want GTK/etc binaries to be taken from random locations (be it the system or build.rs doing that) when building an application but you need to have control over what exactly is happening there.

gtk-rs does not depend on GTK installed on the system, you can point it to a GTK installation in any location you want via pkg-config. Including a private one for your application only.

That's also how @GuillaumeGomez and I handled this at the RustFest workshop in Rome. See https://github.com/sdroege/rustfest-rome18-gtk-gst-workshop/ for details and the binaries that were used there for Windows.

sdroege commented 5 years ago

I disagree, it is something that could be addressed with better cargo packaging.

Also no matter what we do here, if you happen to have an incompatible DLL somewhere in your PATH then things will fail. You have to then ensure in your application that the path to the correct DLLs is placed correctly in the PATH, which is just a standard Windows packaging/deployment problem in the end.