Deluge Forum

Thanks mate

I just checked my computer now, and I genererated a list of files needing to be copied from gvsbuild\release\bin folder of my installer and into the corresponding folder of a newly built gvsbuild. I haven't built gvsbuild mind you, but just tested with Cas's gvsbuild compared to my gvsbuild.

If you ever compare my gvsbuild to yours or Cas's, then you'll also see there is missing alot of files in mine, as I deleted alot of files in general, to save several 100MB footprint, as deluge didn't reference those anyways(done by trial and error).

When simply just replacing my gvsbuild with another, e.g. the one from Cas, then I got exact same error about something failing and only thinclient mode available and then couldn't start daemon from the UI afterwards anyway.

Ohh, the UI will look strange, because in my gvsbuild there is added a settings.ini file under gvsbuild\release\etc\gtk-3.0\settings.ini: (I added some other themes also, which you can get by copying over from my gvsbuild to yours the folders gvsbuild\release\share and gvsbuild\release\etc, the last folder not needed if making above settings.ini file yourself, but if copying share folder mentioned before, then change win32 to win32x in that settings.ini to get an additional bugfix)

Btw, also why I didn't looked into building gvsbuild myself more, after getting errors, was that atleast at the time, then gvsbuild by default used gtk 3.22 and Cas forked gvsbuild and made several changes so it used instead 3.24, so we should use Cas's forked gvsbuild when building, but then this would give us the exact same anyway as Cas's already build and provided pre-made gvsbuild as compressed archieve i'm thinking/guessing, unless changing build-files again to build newer version, if newer released(haven't checked myself) and that is sometime not that easy, so i'm not sure if we gain anything by just running Cas's fork, or the official project, in terms of updated gtk3+, though maybe i'm misunderstanding something.

If continue have problems with gvsbuild and if I cannot help more, though feel free to ask of-course, then i'd suggest pinging doadin which I think knows about how to build and use gvsbuild, since he has made batchfiles available for that, so seemingly done it himself. I don't think he uses this installer, but his own manual build, but that should be the same regarding that(gvsbuild), except needing in that case add yourself the path of the bin folder of gvsbuild to your PATH env-var and install msvc runtimes additionally(though if using deluge from my installer and replacing its gvsbuild with your own built version, then you don't need these things and just need copy over the files listed below, from old to new gvsbuild's bin folder).

Good luck!
(I originally just included all the runtime files as the ones I guessed possibly wasen't needed where so small anyway(~20kb) and hence I didn't bother spend time on finding which was needed specifically, but I now tested it and found only two of all the runtime files needed there specifically, and rest unreferenced so deleted them from my installer now, though only makes a miniscoule space saving but regardless, so if seeing extra runtime files in my gvsbuild's bin folder in an earlier installer than the ones I just now am rebuilding, then it's because of that. Lastly, in my gvsbuild's bin folder I also now saw that I had two python dll's in there which wasent needed, though doesn't hurt neither, but I also now removed them and will not be there from now on either. I had to rebuild anyway to catch up with latest commits of libtorrent 1.2.x, though nothing important added there but regardless, I like being on top of things. Those python files where from long ago when I experimented back and fourth in different ways for trying to get deluge to run without needing touching your real PATH env-var permanently(which could have issues in rare cases I found, when done from scripting, so didn't like doing it, although I did back it up first, but regardless) and instead only touch it temporarilly for the running session only, by utilizing the addition of a PTH file in correct place including some added few lines of python code, though that is located elsewhere and not in gvsbuild, so don't worry about that as already in place when using my installer.)

Sorry, just wanted to clarify to anyone wanting to build gvsbuild yourself, that things have changed I see now, and so don't do like I stated about using Cas's fork, and just use the original project which was updated to latest gtk+3 3.24.14, and I see doadin also made his batch file use that.

The version I use from Cas, is though only under 6 months old roughly, and about 2 minor point releases before newest, but still 3.24 version(3.24.12 I believe, from matching release-date), so I don't know how much changed really since still in minor versions, but anyway I decided to give it a shot again and downloaded and installed all components, and where I had to register with some bogus mail to even get the older supported msvc community edition from msft, instead of mine 3 different msvc toolset versions not officially supported and I previously failed once, when trying to use one of them, and then when almost installed finished the several GB download and install, then my VM crashed because I was to stupid apparently to check if having enough virtual hdd space available and virtualbox got a permanent fit regarding that VM as had overwritten a template file of it(also reported online I read), so then I honestly lost motivation again and restored from a backup of the VM I had, and decided to possibly try again another day. Damn...

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: 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.

OK, I decided to pick at it some more as hate such unresolved failures lurking in the back of my mind, lol Anyway, I rerun build-job and checked command-output more thoroughly, and found now that the cl.exe command does include an include directive for a folder named gdk-pixbuf-2.0, however that folder is not there where specified. Then I tried copying it over manually and rename, but still no go. Then I checked further in the previous command-output, and saw that there where a failure in copying that folder over, from it's correct place and into the include dir as folder gdk-pixbuf-2.0. The reason it fails, is "ninja install" returns non-zero exit status 1, and before that it fails copying over, because it couldn't recognize image file format for a png file in 'tests' subfolder of gdk-pixbuf folder, and later with "no such file or directory", when looking for 'tests\resources.c'.

There where no gvsbuild info on this as stated before, but now with more descriptive error-lines to search for, then I found bug-reports for another app on freebsd using gdk-pixbuf and running into same issue, which was:

It's due to a missing dependency in the build order of ninja created by meson.
For the time being, we use -Dinstalled_tests=false and this patch as a workaround"

Source: https://bugs.freebsd.org/bugzilla/show_ ... ?id=234784

So I applied said patch and building continues past previous sticky point thankfully, well, except a failure of a missing needed runtime file now, which is strange because was available in python's folder which was added to PATH, but whatever, I added it also to system32, rerun, and lo and behold finished without any errors reported and reports gtk3 built now! It did for some reason show alot of missing png's during the building of adwaita gtk3 icon theme, but I hope it's related to the cursors theme, which is anyway something I delete from Cas's build because not used by deluge anyway, even with adwaita theme selected, so hopefully not an issue for us, but I gotta do some more testings now and see if everything is kosher now with the new gvsbuild on-top-off deluge, and hopefully I soon can build and upload new rebuilds of the installers now with latest gtk3 stack included

Edit: Looks good to me Will edit here again when having rebuilded installers with new gtk3 stack.

Edit2: Done.

Congratulation with finishing building gtk3! My build went uneventful besides a need to specify the path to VS2017. Somehow, it would find the right one but would still use the hardcoded. I have Windows 7 x64, VS2017 Community. I am building openssl right now and have a few problems with tests (stuck on 30-test_evp). Do we need static or dynamic openssl libraries for Deluge?
Hello to everybody! I'm new here, happy to find this forum. Agapa

Thank you agapa, appreciate that mate, and welcome to this community and glad to have you on board

Ohh, that surprices me that you didn't have a gdk-pixbuf building issue, but as said there where also no reports on gvsbuild bugtracker about it. I too used the compiler you did, and specify path to it and whatnot(version etc), but was on a win10 VM and not win7, though shouldn't really mater much I'd guess. I used latest 3.7 python, so v3.7.7, so maybe related to that specific version regarding meson, but atleast I see I'm not alone in experiencing this general gdk-pixbuf/meson issue from online, e.g from where I got the patch from etc.

I got as said also into the issue of having conflicting files of gtk3 components in system32, which others reported here too during using this deluge installer, because I had not long ago temporarilly installed a few windows gtk3 apps, just to see how they handled theming and if anything worth borrowing from them regarding good windows gtk3 theme, or mods to adwaita default gtk3 theme, to use for this deluge installer, but didn't find anything other than default adwaita, and uninstalled them again, and of-course windows have this nice habit of both installing app files into system32 without informing you, but also not removing them upon uninstall! I'm honestly glad I'm not using windows for anything except this little project here.

Anyway, I personally don't bother build openssl, as the dynamic link libraries are anyway available pre-built for windows in latest versions, so I just add the crypto=openssl to b2 build options for libtorrent, and then have the header files of openssl available under C:/OpenSSL-Win64 and after libtorrent.pyd is built, then I copy latest openssl dynamic libraries over to deluge(just the libcrypto* and libssl* 2 dll's) in addition to the libtorrent.pyd dynamically linked to them, and done.

I get them same place as Cas, pre-built, so never saw the need to reinvent the wheel for that, so to speak, for no apparent gain: https://slproweb.com/products/Win32OpenSSL.html The light package is just the dlls, but the full package is needed for the header files used when building libtorrent with openssl support(https tracker announcing support).

I hope you can fix your issue with the OpenSSL building, if still continuing that route. Good luck mate!

Edit: Just a quick look-see revealed someone fixing error of said file, by upgrading to, at the time, latest nasm for windows x64, v2.14.02, though was 9 months ago or so, and with VC2013, openssl 1.1.1b and win7, but maybe still related, who knows.

Sorry, forgot to also replace the extra files I previously had copied out from gvsbuild and into main deluge folder and further down into a specific subfolder, to fix issue of conflicting files from system32 used instead of the ones from deluge install, e.g. cairo.dll, freetype.dll, zlib1.dll and libpng16.dll, so I now replaced those with the ones from new rebuilt gvsbuild also.

I rebuilt libtorrent 1.2.x also while at it, e.g. there where a fix to openssl code, which one reported fixed issue of sometimes getting tls errors when announcing to https trackers.

Btw, the installed size has gotten up about 25 MB with this gtk3 stack update, but that is mainly from bigger localisations folder I could see, and didn't wanted to remove any of that, though could save over 40mb from ditching non-US locales, but I didn't wanted do that since deluge features localisation support. There are some more space to be saved from further pruning the deluge and gvsbuild out for unneeded files/folders, but didn't wanna spend more time on that atleast for now, since as stated before, already reduced several 100 mb's as of yet, and it's time-consuming as done through trial and error, untill the freezing part is fully working which does that automatically I believe(checks for and includes only referenced files during the freezing-process).

Edit: Just a headsup, i'm gonna rebuild soon again, so might as well hold up and wait a little for next rebuild, as saw e.g. twisted where updated etc, and there where also a new gtk3 release issued a couple days ago and newer than the one used by gvsbuild, so i'll see if I can edit gvsbuild to build with this newer gtk3 version instead.

As I edited into last post, then new gtk3 version released a couple days ago, and gvsbuild hasen't updated to include that yet, and while I edited the sources of gvsbuild correctly to instead download and build with newest gtk3, then it failed building with a ninja build error, as probably missing some patches which usually is added to gvsbuild upon new gtk3 release for proper compatibility, so we'll have to wait for official support for that.

Btw, the old gtk3 used from Cas's gvsbuild, was older than I thought and 7 versions behind this gtk3 version I included now, and although not the newest as of 2 days or so, then only a months old roughly, whereas the older used one where little over a year old. I hope this will fix some of the GTKUI UI issues/annoyances reported previously in this thread hopefully.

I also rebuilt deluge using updated versions of twisted, pycairo and pygobject and I reverted the patch from tobbez, that as workaround disabled *.ico tracker icons, to avoid a sometimes crashing issue of gdk-pixbuf in gvsbuild, but as we now use latest gdk-pixbuf package which is 2 versions newer than last time, then the problem very possibly could be fixed now, and i'll instead wait to see if that error gets reported again, and if so, i'll of-course re-add the patch. This will make *.ico tracker icons now show up correctly, which in previous releases where hidden/disabled and only would show if in png format.

Mhertz, good luck!
I switched (from master) to openSSL 1.1.1-stable, and all the tests ok-ed. I have libtorrent.pyd built (but not tested), downloaded deluge-deluge-2.0.3.zip, and now I trying to figure out what to do next.

Good job! Let me know if I can help with something. Just in case you hadn't seen, then there are instructions from Cas here: https://dev.deluge-torrent.org/ticket/3201 and doadin's batch-files for building deluge, libtorrent, gtk3 and openssl: https://github.com/doadin/DelugeBuildFromSource