I didn't succede as usual, but I spent several hours yesterday trying get gvsbuild(gtk3 stack for windows) built propperly, and today too, but still no luck, and beginning to piss me off honestly, lol
I don't think I have more patience to mess with it more for now atleast, well unless getting help from someone or if someone in the know could build it and send it to me to include in installer, I'd rather do it myself though, but cannot do it as of yet unfortunetly, as said.
The instructions didn't say git was a needed dep, and although I had it installed and in path already, from my cygwin install, then I removed cygwin from path temporarilly, while trying build gvsbuild, as wouldn't have compatibility issues regarding both msys2 and cygwin in path with same exe-names, but I figured it out by checking the log and just installed git from msys2 also and got further, but I always have some components missing at the end, 9 components missing, and gtk3 is one of them, jeez.
Msft in there brilliant minds, decided to have path variations between a vc-toolset when installed from a 2017 installer or a 2019 installer which has a 2017 install-checkbox also, plus they have differences in vcvars files etc, so to get no issues, even though having vc-toolsets 2015, 2017 and 2019 installed, then I installed the fully supported as stated, VC community edition 2017, which includes and uses vc-toolset 2017(but with changed install-path and vcvars files, compared to my other installed vc-toolset 2017
).
It did begin building now, and overcome the previous issues, and then after fixing the git issue, then it builds in a long time and end with 9 missing components, e.g. gtk and gtk3 etc. I also don't get why gtk(2) is defined to build by Cas, and hence, doadin too?, but I left it alone, and just used doadin's batchfile so didn't have to spend time making my own with the info from Cas's appvoyer.yaml or however it's named. Thanks again doadin!
I added just the skip packages that Cas also added, to doadin's batch(to save build-time and footprint-size, though tested also without to check if that was the issue, but wasent) and some changes to PATH set command etc. When failing there, I tested only with the example from official instructions, i.e. just specifying to install gtk3 or gtk3-full, and adding commands for py37 and path etc, but again no luck.
Little before it fails, there comes up an error-box about missing entry-point in a pango-dll during fribidi-meson install, which I pressed OK too and it continued. When testing with just installing gtk3 as per the docs, then I got a likeminded error, this time though regarding gdk-pixbuf. Anyway, this was the error about the pango.dll:
Code: Select all
installing fribidi-meson
debug: running ninja install ...
[0/95] Generating pango-1.0.git with a custom command
Textbox-error comes up with:
Title: Pango-1.0.exe - entrypoint not found
Rest of error-box: process-entrypoint ft_get_var_blend_coordinates was not found in dll-library C:\gtk-build\build\x64\release\pango-meson\pango\pango-1.0-0.dll
(Translated by me, so not fully precise, as localiced error message)
Then little after there is a python error during install of pygobject, about getting import dll error upon trying import cairo, and then fails installing pygobject, which I guess makes gtk3 to not be installed as needed component there. pycairo is available under python site-packages folder, and it fails in line 1 of __init__.py with the procedure not found and dll load failed, about: "from ._cairo import *". I know Cas made a change to his gvsbuild fork about a cairo lib-name change, but that change has been added upstream too I see.
Afterwards, lz4 gets built, and then ends with 9 missing components mentioned and shows list of what was correctly built.
I could see Cas used VC-2015 and not 2017, but I didn't wanted install that too, with already 4 compilers installed now, and VC-2017 is also the default and fully supported version as per upstream, plus the one used by default by doadin in his batchfile.
Anyway, as said, the gvsbuild included currently in my installers, are under 6 months old, and the new release is just about 2 minor point-releases above and doesn't seem to have many win32 fixes included regardless, but of-course would be nice still to be on-top of all components. Speaking of that, I just noticed there where released a new python version in the 3.7 series a little time ago, but my installers already include that since then(last few rebuilds), because I had made my build-script to find, download and install/use the latest py37 anyway. There where also updated openssl I had missed, and so i'm rebuilding now to include that, plus I updated to latest geoip database from maxmind(3'rd party built, using latest database content, as not available for free from upstream anymore, and last free version is rather outdated by now - the one I include is also used by e.g. transmission too).
Sorry for long post, and just in case I have included the full build-log of gvsbuild run, though not all errors shown there, e.g missing both the python cairo import error and the error-box of the pango dll entry-point missing, which I got from the command-prompt output of script(and error-box) as added a 'pause' command at end of doadin's script:
https://pastebin.com/5Lqe84kC
Edit: Btw, the missing entry-point in dll error, though in other dll, I remember got reported before in this thread, and I could reproduce, when having another version of that, or related dll in system32 folder, or in PATH, so windows looks at wrong dll and cannot find what looking for in that. I believe it was fontconfig or freetype or libpng16.dll, and exact same reference point missing, even though supposedly mentions correct file, but in the deluge case, it always was issue with other related file for some reason, so hard to fix. I will have to check if having this, or related files in system32 then and recheck, but still im not sure it's related to the Cairo import issue, but could be though.
Edit2: OK, found not pango but related file, freetype.dll in system32 and moved elsewhere for test and rerun, and then same error, though this time regarding libpng16.dll. Not having that either, but found cairo.dll in system32 and moved away for test, and rerun, and same error again, and I found in system32 zlib1.dll(good that I remembered the troublesome filenames to search for, from the deluge issues I previously fixed here), but unfortunetly then even now without any error-boxes, then it now ends with simply 2 less components missing, but still missing 7, including gtk3
Well, it's 2 missing components gdk-pixbuf and cogl, and then 5 missing dependencies to those, where gtk3 is included there. Inspecting command-output reveals the error is cogl fails build because this command returns non-zero exit status 1: "msbuild build\win32\vs15\cogl.sln <lots of suboptions e.g. python-path etc>". before that there is error: "C:\gtk-build\build\x64\release\cogl\cogl\cogl-bitmap-pixbuf.c(46): fatal error c1083: cannot open include file: 'gdk-pixbuf/gdk-pixbuf.h': no such file or directory [C:\gtk-build\build\x64\release\cogl\build\win32\vs15\cogl.vcxproj]". I made a search for that missing include file, and found it in: C:\gtk-build\build\x64\release\gdk-pixbuf\gdk-pixbuf\gdk-pixbuf.h. The rest mentioned files exist I see also. I don't know how to get further now? Any thoughts please? I tried copying the gdk-pixbuf folder over into folder of cogl C file requesting it, and edited the include directive off said C file to import it from relative path, but still fails for me as then another file now is missing, as the header file also calls it's files in same "faulty" way. I don't know how to procede, and couldn't find reports about this on gvsbuild bugtracker, and googling it in general just showed people having that error with other apps just needed install a package they where missing on Linux, which doesn't apply here.
Deluge
