Add Apple Silicon native support
adi1382 opened this issue Β· 143 comments
Please provide the following information
qBittorrent version and Operating System
macOS Big Sur (arm64)
If on linux, libtorrent-rasterbar and Qt version
(type here)
What is the problem
Native support on apple silicon
What is the expected behavior
(type here)
Steps to reproduce
(type here)
Extra info(if any)
Hey, Does the team have plans to release binary that would run natively on apple silicon?
Good question
@adi1382 @Mr-Beetroot I can only presume that you have tried 4.3.3 & it doesn't work? Does it not run at all or crash?
Ignore, Irrelevant - asked in wrong issue.
@xavier2k6 I think they are requesting a native version i.e an arm version of qbittorrent.
@xavier2k6 I think they are requesting a native version i.e an arm version of qbittorrent.
Ya, I already tagged as Feature Request - asked in wrong issue......IGNORE.
So will there be a eta on universal build?
We have to wait at least until Qt supports M1 Macs.
successfully compiled master branch commit ab6141e for Apple M1 !
see last line in command line on screenshot, file type reported is arm64! no Rosetta installed on used MacBook !
qBittorrent runs as native ARM64 app, and it works!
you can download experimental build here (link to Dropbox)
please note this is NOT universal binary, this is arm64 only (i.e. only for Apple Silicon based Macs)
P.S> I DON'T own an Apple Silicon based MacBook, laptop used for building I got from office due to my work responsibilities. I just used it because it has suitable development environment and I was curios.
P.P.S> I'll try to produce arm64 binaries using Intel-based MacBook, but this is later. it should be possible, at least because I saw x86 binaries produced on this Apple M1 on first try...
Unofficial qBittorrent 4.3.4.1 release for Apple M1
compiled using the same libraries versions as official
no any source code changes, 332b173
for Apple M1 only, NOT universal binary
>>>download release 4.3.4.1<<<
@Kolcha How did you handle Qt? I thought that Qt would only get support for M1 in a future release. Surprised to see that Qt 5.15.2 works out of the box.
@FranciscoPombal even 5.12.x works :) but not exactly "out of the box" :)
all I did that changed only one line in some Qt' mkspecs file. and that change was caused by very unexpected thing - I got x86 Qt' binaries (moc was among them)! and system complained that something can't be executed (because I don't have Rosetta (I must have clean environment)
after that change build process went fine. also I see no reasons to concern about Qt, because it supports arm64 architecture for a long time (at least because it is available for Android and Yocto Linux which is popular across different embedded systems, mostly ARM-based).
moreover, only one thing I concerned was OpenSSL (due to its uncommon and maybe unique own build system), but seems it is already ready for M1, its build script even had some preset something like darwin20-arm64 (approximate name, don't remember). in all other things I was almost sure that it will not cause any build issues (thanks to my work experience...)
I'll share all my work later, when I find the way to build Qt' arm64 binaries on x86 host (anything else I think should not cause serious issues), but this looks like even harder challenge that compiling Qt 4.8 with VisualStudio 2017 (especially when I'm even not experienced Windows user...) that I did few years ago...
Thanks for the details.
I'll share all my work later, when I find the way to build Qt' arm64 binaries on x86 host (anything else I think should not cause serious issues), but this looks like even harder challenge that compiling Qt 4.8 with VisualStudio 2017 (especially when I'm even not experienced Windows user...) that I did few years ago...
I'm happy that you're looking into cross-compiling with x86-64 hosts - this means that we can create a GitHub Actions workflow for the procedure and get macOS ARM test builds working even before (if ever) GitHub introduces native macOS ARM runners. Still, I would suggest documenting the current build procedure (native compilation) on a wiki page and link it here, at your convenience. This will give ARM macOS users something to chew on before the cross-compiling workflow is ready.
Unofficial qBittorrent 4.3.5 release for Apple M1
no any source code changes, 063844e
for Apple M1 only, NOT universal binary
>>>download release 4.3.5<<<
P.S> still no any documentation / tips & tricks for build process on M1, neither any progress on cross-compiling from x86_64 to M1 (even did not any research on this yet). sorry, I'm too busy now... and after work I'm too tired and just don't want to work on something else so energy-consuming... but build and publish new release requires only few minutes and no thinking.
finally, I had some free time when I was not so tired. and there are some good news - I got arm64 qBittorrent executable on my x86_64 host!
but there is one very inconvenient thing - Qt' very convinient tool called macdeployqt is only for target architecture (i.e. arm64), and it is can't be compiled for host (I tried, but no luck, very likely there is must be the reason for it)...
some tricks were also required to cross-compile Qt to M1, there is NO any presets/configurations/options for that, but in general Qt is ready for it. my experience with Qt 4.8 compilation using MSVC 2017 and a lot of experience in cross-compiling on Linux helped me a lot here :) but process is still different from usual cross-compilation, because you are using the same compiler... this is unusual...
also I would like to add few words about so-called "universal (or fat) binaries". such kind of binaries are extremely easy to build, but ... only if code is really cross-platform (i.e. rely on only standard library). so in such cases as Qt (and moreover OpenSSL) it is unacceptable, because their code rely on specific CPU instructions which are completely different for x86_64 and arm64, and code doesn't not have platform-dependent switches, decisions what to use are made only on "configure" stage, i.e. the same code will be tried to be compiled for each architecture, and this doomed to fail (tested with Qt, I even didn't thought that it so much depend on certain CPU instructions).
so, now I see the "whole picture" and have some thoughts what to do next, and the end is near. in few days I'll publish at least guide describing all tricks used to make build possible on native M1. cross-compiling manual will appear later, I have to solve few more issues to make this process smooth and easy to automate.
so, wait for updates, very likely native Apple Silicon builds will be officially available with next qBittorrent release :)
Great news all around, nice work.
also I would like to add few words about so-called "universal (or fat) binaries". such kind of binaries are extremely easy to build, but ... only if code is really cross-platform (i.e. rely on only standard library). so in such cases as Qt (and moreover OpenSSL) it is unacceptable, because their code rely on specific CPU instructions which are completely different for x86_64 and arm64, and code doesn't not have platform-dependent switches, decisions what to use are made only on "configure" stage, i.e. the same code will be tried to be compiled for each architecture, and this doomed to fail (tested with Qt, I even didn't thought that it so much depend on certain CPU instructions).
Is there any advantage in providing fat binaries as opposed to one build for each architecture? If not, you don't need to worry about them if you don't want to, because I doubt anyone else has strong opinions about this.
Is there any advantage in providing fat binaries as opposed to one build for each architecture? If not, you don't need to worry about them if you don't want to, because I doubt anyone else has strong opinions about this.
there is only one advantage - developers ship only one binary and end users don't need to think what to download. technically there are no any benefits, only head ache for developers in case of non-trivial code :) I don't worry about fat binaries and I don't want to provide them, I prefer to ship 2 different builds, users will be able to choose one (I think users are not so stupid to do not know is their Mac based on Apple Silicon or Intel chip, IMO).
moreover, providing 2 different binaries is preferable from used space point of view - space is used only by code what you will use, no any bloat. so, I'm focused on two separate builds.
@FranciscoPombal
I added the Wiki page describing the build process, feel free to edit it because I don't think that I'm good enough in English.
document covers all cases: native building for x86_64 and arm64, and also cross-compilation. all steps almost the same (only one option is different depending on build type), so it was decided to create one common document. it is should be pretty easy readable even for newbies.
the most unusual (and what was complex) part is documented in details, so anyone should be able at least just to repeat that.
also I published totally new and much more "developer friendly" fully automated script for qBittorent building in any variant (even with easy way for switching dependencies versions). there is the link. script is not big and very simple. the most interesting parts of it is pretty well commented too (and most of that comments became a part of documentation). you may use it as starting point for GitHub Actions workflow.
finally, I had some free time when I was not so tired. and there are some good news - I got arm64 qBittorrent executable on my x86_64 host!
but there is one very inconvenient thing - Qt' very convinient tool called
macdeployqtis only for target architecture (i.e. arm64), and it is can't be compiled for host (I tried, but no luck, very likely there is must be the reason for it)...some tricks were also required to cross-compile Qt to M1, there is NO any presets/configurations/options for that, but in general Qt is ready for it. my experience with Qt 4.8 compilation using MSVC 2017 and a lot of experience in cross-compiling on Linux helped me a lot here :) but process is still different from usual cross-compilation, because you are using the same compiler... this is unusual...
also I would like to add few words about so-called "universal (or fat) binaries". such kind of binaries are extremely easy to build, but ... only if code is really cross-platform (i.e. rely on only standard library). so in such cases as Qt (and moreover OpenSSL) it is unacceptable, because their code rely on specific CPU instructions which are completely different for x86_64 and arm64, and code doesn't not have platform-dependent switches, decisions what to use are made only on "configure" stage, i.e. the same code will be tried to be compiled for each architecture, and this doomed to fail (tested with Qt, I even didn't thought that it so much depend on certain CPU instructions).
so, now I see the "whole picture" and have some thoughts what to do next, and the end is near. in few days I'll publish at least guide describing all tricks used to make build possible on native M1. cross-compiling manual will appear later, I have to solve few more issues to make this process smooth and easy to automate.
so, wait for updates, very likely native Apple Silicon builds will be officially available with next qBittorrent release :)
Doesn't work on M1 Big Sur. Please see attachment.
@monotheist dialog you see is expected - app is not signed, I don't have extra 100$+ to pay Apple for signing certificate, even more such certificates are expire in a year.
so, as for many other free and/or open source apps, just go to the settings and press "Open Anyway". you will be not prompted next time.
@monotheist dialog you see is expected - app is not signed, I don't have extra 100$+ to pay Apple for signing certificate, even more such certificates are expire in a year.
so, as for many other free and/or open source apps, just go to the settings and press "Open Anyway". you will be not prompted next time.
Thank you
According to this: https://www.qt.io/blog/qt-on-apple-silicon
...Qt intends to support compiling for Apple Silicon to Qt 5.15 as well. Since Qt 6 drops support for a lot of platforms that users still use, my recommendation is to wait for the Qt 5.15 branch to have proper Apple Silicon support (hopefully with the official frameworks being universal binaries, or at least adding support for compiling universal binaries) and then start building qBittorrent using that.
qBittorrent-master-macOS-arm64.dmg.zip
Here is a build for version 4.4.0.Beta1
According to this: https://www.qt.io/blog/qt-on-apple-silicon
...Qt intends to support compiling for Apple Silicon to Qt 5.15 as well. Since Qt 6 drops support for a lot of platforms that users still use, my recommendation is to wait for the Qt 5.15 branch to have proper Apple Silicon support (hopefully with the official frameworks being universal binaries, or at least adding support for compiling universal binaries) and then start building qBittorrent using that.
Well, Qt 5.15 LTS is only for commercial users......so the only way is Qt6 :)
Well, Qt 5.15 LTS is only for commercial users......so the only way is Qt6 :)
That's garbage! Boo on the Qt Company for not supporting open source. Qt 6 cuts out support for Windows 7, Windows 8, macOS 10.13, and Ubuntu 19.10 and earlier, all of which are reasonable to still be using on older hardware or simply because users don't agree with the direction the operating systems have gone in. (I'm looking at you, Windows 10 and macOS Big Sur.)
I hope the developers of qBittorrent opt to maintain at least Qt 5.15 compatibility for a while longer and not drop these users.
Unofficial qBittorrent 4.3.6 release for Apple M1
no any source code changes, ac8105c
for Apple M1 only, NOT universal binary
>>>download release 4.3.6<<<
compiled using slightly modified version of my script
P.S> very likely this is my last contribution regarding macOS. I sold my personal very old MacBook Pro, M1-based MacBook I have from work will also be given to another developer soon, so I will not have any Apple devices anymore. going back to Linux, like it was many years ago... and I'm very happy
qBittorrent-master-macOS-arm64.dmg.zip
Here is a build for version 4.4.0.Beta1
how did you get the link? been trying to check if there's an artifact in github actions
qBittorrent-master-macOS-arm64.dmg.zip
Here is a build for version 4.4.0.Beta1how did you get the link? been trying to check if there's an artifact in github actions
I used @Kolcha s script. It did everything automatically.
If you want to compile 4.3.7 for yourself, line 32 of @Kolchaβs script would be:
qbittorrent_ver=release-4.3.7
Other changes I made are here: https://gist.github.com/Kolcha/3ccd533123b773ba110b8fd778b1c2bf#gistcomment-3844205
@kjoonlee , to change version of something used in script it is not necessary to edit it - versions can be specified as command line arguments, see line 70 and below. in your case specifying qbittorrent and libtorrent versions next options can be passed:
--qbittorrent=release-4.3.7 --libtorrent=1.2.14
versions hardcoded in the script are just defaults, and was latest at the time of writing. I don't have any MacBook anymore, so the script will not be updated (anymore, it was written without any further updates in mind, so why options where added).
in any case, thanks for your comment about required changes to build release! this is good hint for other users who will decide to try this script. it is nice to see that this script was useful for someone.
This one is a build for version 4.4.0beta2.
qBittorrent-master-macOS-arm64.dmg.zip
Built using @Kolcha script π Thank you! π
I changed some of the libraries version to the latest compatible version following the wiki.
So far, it's working smoothly without any problem.
Using it with both private and public torrent.
Search engine also working fine.
I built 4.3.7 using the script changes from @kjoonlee
qBittorrent-release-4.3.7-macOS-arm64.dmg.zip
@vineryap What are the changes with 4.4? Is that posted somewhere?
@kopaka7 No they didn't or maybe haven't give any detail about the changes with version 4.4 aside from using the libtorrent 2.0.x series. https://www.qbittorrent.org/news.php.
I didn't change the qbittorrent version when running the script, so it used the latest one.
To build 4.3.8, after adding ,qtmacextras to line 156:
./build_qbt_dmg.sh --qbittorrent=release-4.3.8 --openssl=1.1.1l --boost=1.77.0 --libtorrent=1.2.14 --cmake=3.21.2
To build 4.3.8, after adding
,qtmacextrasto line 156:./build_qbt_dmg.sh --qbittorrent=release-4.3.8 --openssl=1.1.1l --boost=1.77.0 --libtorrent=1.2.14 --cmake=3.21.2
Can you send the build 4.3.8?
Can you send the build 4.3.8?
Here you go
qBittorrent-release-4.3.8-macOS-arm64.dmg.zip
Can you send the build 4.3.8?
Here you go
qBittorrent-release-4.3.8-macOS-arm64.dmg.zip
can u send the beta 4.4 3 version as I check with activity monitor, beta version (4.4) using far less memory than official release. tq so much
Can you send the build 4.3.8?
Here you go
qBittorrent-release-4.3.8-macOS-arm64.dmg.zipcan u send the beta 4.4 3 version as I check with activity monitor, beta version (4.4) using far less memory than official release. tq so much
I used this command to build it:
sh build_qbt_dmg.sh --qbittorrent=release-4.4.0beta3 --openssl=1.1.1l --boost=1.76.0 --libtorrent=2.0.4 --cmake=3.21.2
I wanted to use Boost 1.77 and Libtorrent 2.0.4 but i had an error so i used Boost 1.76
Can you send the build 4.3.8?
Here you go
qBittorrent-release-4.3.8-macOS-arm64.dmg.zipcan u send the beta 4.4 3 version as I check with activity monitor, beta version (4.4) using far less memory than official release. tq so much
I used this command to build it:
sh build_qbt_dmg.sh --qbittorrent=release-4.4.0beta3 --openssl=1.1.1l --boost=1.76.0 --libtorrent=2.0.4 --cmake=3.21.2
I wanted to use Boost 1.77 and Libtorrent 2.0.4 but i had an error so i used Boost 1.76
tq so much
What's still preventing @Kolcha's build script from building official macOS Aarch64 builds? I've been using unofficial binary generated by the script and it's indeed work just fine. Although official release on qBittorrent download page would be nice. Take some time lurking GitHub issues to find Aarch64 unofficial builds.
Out of curiosity, how much memory consumption do you guys see when using the build from that script?
For me it's about 300MB to 500MB with no advance settings tweak and less than 100 torrents.
Is it normal?
I tested rtorrent and Transmission daemon consumes less memory maybe because of no GUI.
Out of curiosity, how much memory consumption do you guys see when using the build from that script? For me it's about 300MB to 500MB with no advance settings tweak and less than 100 torrents. Is it normal?
I tested rtorrent and Transmission daemon consumes less memory maybe because of no GUI.
out of box setting with 2 concurrent downloads.
Out of curiosity, how much memory consumption do you guys see when using the build from that script? For me it's about 300MB to 500MB with no advance settings tweak and less than 100 torrents. Is it normal?
I tested rtorrent and Transmission daemon consumes less memory maybe because of no GUI.
I have the v4.4.0beta3 version and the memeory usage is below 100 Mb with a few download tasks
I'm using v4.4.0beta3 and it use the memory around 300MB with 2 active torrents.
Not sure if this is normal or not.
Can you send the build 4.3.8?
Here you go
qBittorrent-release-4.3.8-macOS-arm64.dmg.zipcan u send the beta 4.4 3 version as I check with activity monitor, beta version (4.4) using far less memory than official release. tq so much
I used this command to build it:
sh build_qbt_dmg.sh --qbittorrent=release-4.4.0beta3 --openssl=1.1.1l --boost=1.76.0 --libtorrent=2.0.4 --cmake=3.21.2
I wanted to use Boost 1.77 and Libtorrent 2.0.4 but i had an error so i used Boost 1.76
qBittorrent-release-4.4.0beta3-macOS-arm64.ziptq so much
could you tell me how do you install qmake on m1 MacBook? I use brew to install qt,but the make version is 3.1 while configure need Qt5 qmake >= 5.15.2
@waruto210 don't use Homebrew if don't have strong reason for it, especially when try to build some GUI apps. Homebrew is evil in most cases, but unfortunately this is necessary evil...
I don't know what Qt version and how it is packaged in Homebrew, in any case I recommend to build Qt by yourself (because as far as I know there is no official Qt 5 release for M1, but I can be wrong). You can find the way how to build Qt for M1 in my script https://gist.github.com/Kolcha/3ccd533123b773ba110b8fd778b1c2bf . even it is pretty big, but it is very simple - this is just a sequence of commands just for automation, nothing more. and it is pretty well-commented (especially Qt building part). so it is not so hard to find interesting part even you are not familiar with bash.
also you can find more details on Qt building for M1 in my manual here https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-macOS-(x86_64,-arm64,-cross-compilation)
@waruto210 don't use Homebrew if don't have strong reason for it, especially when try to build some GUI apps. Homebrew is evil in most cases, but unfortunately this is necessary evil...
I don't know what Qt version and how it is packaged in Homebrew, in any case I recommend to build Qt by yourself (because as far as I know there is no official Qt 5 release for M1, but I can be wrong). You can find the way how to build Qt for M1 in my script https://gist.github.com/Kolcha/3ccd533123b773ba110b8fd778b1c2bf . even it is pretty big, but it is very simple - this is just a sequence of commands just for automation, nothing more. and it is pretty well-commented (especially Qt building part). so it is not so hard to find interesting part even you are not familiar with bash.
also you can find more details on Qt building for M1 in my manual here https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-macOS-(x86_64,-arm64,-cross-compilation)
I tried multiple times on a M1 device, but Qt5 cannot be compiled on XCode 13 without the following patch:
--- a/qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h
+++ b/qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h
@@ -43,4 +43,6 @@
#include <qpa/qplatformgraphicsbuffer.h>
#include <private/qcore_mac_p.h>
+
+#include <CoreGraphics/CGColorSpace.h>
QT_BEGIN_NAMESPACE
Sources : Homebrew/homebrew-core@80e3dc7
https://code.qt.io/cgit/qt/qtbase.git/commit/src/plugins/platforms/cocoa?id=dece6f5840463ae2ddf927d65eb1b3680e34a547
I tried out the patch and I could successfully compile Qt5 with this, and following the mentioned compilation guide I was able to build a 4.3.9 version successfully.
Unrelated note: I even tried to use Homebrew's qt5 to build before I found this patch, but it resulted a false positive build, so the generated build was not able to start.
@Kolcha can you please update your build script and compilation guide to include this patch?
I'm not familiar with how to apply patches through bash (and git in general), so I did the patching manually when I tested it.
Also I upload my build of the latest stable, which built based on the compilation guide and the Qt patch:
qBittorrent-release-4.3.9-macOS-arm64.dmg.zip
Update: Please use the following build instead of the original (thanks @koppanyinorbert for testing and submitting
feedback):
qBittorrent-release-4.3.9-macOS-arm64-signed.dmg.zip
Also I upload my build of the latest stable, which built based on the compilation guide and the Qt patch: qBittorrent-release-4.3.9-macOS-arm64.dmg.zip
I tried it and i have an error.
"qBittorrent" is damaged and can't be opened.You should move it to the Bin.
Also I upload my build of the latest stable, which built based on the compilation guide and the Qt patch: qBittorrent-release-4.3.9-macOS-arm64.dmg.zip
I tried it and i have an error. "qBittorrent" is damaged and can't be opened.You should move it to the Bin.
I tried multiple ways, but couldn't reproduce the issue.
If you can, then please try out the following and paste the log here:
Open a Terminal and run the executable from there as /Applications/qbittorrent.app/Contents/MacOS/qbittorrent
Update: I'm rebuilding Qt5 and qBittorrent just in case.
Update 2: Okay, I have an idea why it fails. The script has a codesign step, which was omitted from the guide, so I forgotten to do it. I'll post a signed build here, once the build is finished.
Also I upload my build of the latest stable, which built based on the compilation guide and the Qt patch: qBittorrent-release-4.3.9-macOS-arm64.dmg.zip
I tried it and i have an error. "qBittorrent" is damaged and can't be opened.You should move it to the Bin.
I tried multiple ways, but couldn't reproduce the issue. If you can, then please try out the following and paste the log here: Open a Terminal and run the executable from there as
/Applications/qbittorrent.app/Contents/MacOS/qbittorrentUpdate: I'm rebuilding Qt5 and qBittorrent just in case. Update 2: Okay, I have an idea why it fails. The script has a codesign step, which was omitted from the guide, so I forgotten to do it. I'll post a signed build here, once the build is finished.
If you need any more information just write me.
Rebuilt and signed latest stable version (hopefully it works):
qBittorrent-release-4.3.9-macOS-arm64-signed.dmg.zip
Rebuilt and signed latest stable version (hopefully it works): qBittorrent-release-4.3.9-macOS-arm64-signed.dmg.zip
this is working, thanks!
@Kolcha can you please update your build script and compilation guide to include this patch?
I'll integrate it in few days, very likely only this weekend. I'm too busy these days, and right now can't upgrade Xcode to 13 on my work MacBook (and don't have any personal Apple' device where I can do anything). so script update will happen, but not so soon, sorry.
@R0GERIUS thanks for that information!
I'll integrate it in few days, very likely only this weekend.
so, I tried. this patch can't be applied to Qt 5.x as is... it is much easier just to modify sources instead.
script update will not happen, sorry
I'll integrate it in few days, very likely only this weekend.
so, I tried. this patch can't be applied to Qt 5.x as is... it is much easier just to modify sources instead. script update will not happen, sorry
Yeah, my bad, it was malformed.
Turns out git patching is very sensitive to end-of-line characters and it was missing the end-of-line character, thus it wasn't possible to actually apply it.
Based on this, I generated a patch with git with the correct formatting, and it's available here:
https://gist.github.com/R0GERIUS/a2d62e21995e732b9fe510efce71965d
Raw version:
https://gist.githubusercontent.com/R0GERIUS/a2d62e21995e732b9fe510efce71965d/raw/26e9f02b88d6eb41b3a6b636248d6290094ecdc9/qt5_xcode13.patch
Adding the two related lines to the script, which downloads and applies it, made the script perfectly working on my end.
A possible caveat is, that I was unable to test the solution with the system/XCode included git, since I'm using the newest stable version.
I also left a comment on the script itself about what should be added for XCode 13, if anybody wants to test it out.
Hi @rogerius I'm on an M1 iMac running macOS Monterey v12.0.1 and Xcode v13.1
When I run the script it fails with the following:
/private/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.0WUlYQ6B/src/qt-5.15.2/qtbase/src/plugins/platforms/cocoa/qcocoaglcontext.mm:508:19: warning: 'view' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
if (m_context.view.layer) {
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: 'view' has been explicitly marked deprecated here
@Property (nullable, weak) NSView *view NS_SWIFT_UI_ACTOR API_DEPRECATED("", macos(10.0,10.14));
^
15 warnings generated.
make[4]: *** [sub-cocoa-make_first] Error 2
make[3]: *** [sub-platforms-make_first] Error 2
make[3]: *** Waiting for unfinished jobs....
rm -f /private/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.0WUlYQ6B/build-arm64/qt-5.15.2/qtbase/plugins/sqldrivers/libqsqlite.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cq -S /private/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.0WUlYQ6B/build-arm64/qt-5.15.2/qtbase/plugins/sqldrivers/libqsqlite.a .obj/qsql_sqlite.o .obj/smain.o .obj/sqlite3.o .obj/moc_qsql_sqlite_p.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib -s -no_warning_for_no_symbols /private/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.0WUlYQ6B/build-arm64/qt-5.15.2/qtbase/plugins/sqldrivers/libqsqlite.a
make[2]: *** [sub-plugins-make_first] Error 2
make[1]: *** [sub-src-make_first] Error 2
make: *** [module-qtbase-make_first] Error 2
disregard my last. I thought the change was incorporated into the main script, but after looking it over found it hasn't yet. I added it in, ran the script, worked perfectly. thanks!
Note: release-4.4.0rc1 cannot be built on macOS Monterey 12.0.1 with XCode 13.1 on ARM platform.
The issue is resolved on the master branch with the following commit: 7aa859a
What is missing now to make an official universal build?
This story again shows how c++/QT is really not the best option for industry.
Even after we have got m1 max and others, we can't have native builds.
with Kolcha's script and Rogerius's patch, I was able to get a native build on my M1 iMac. Works great. Sometimes all it takes is collaboration between people who together have the right knowledge
So maybe we just need to crowdfund for mac mini m1 for maintainer?
Let's start campaign?
I mean common. There are m1 max out there already. The x86 king is dead, long live the arm king. There are thousands arm computers out there, demand is pretty high.
What is missing now to make an official universal build?
I have some ideas, but these are guesses, so take it with a grain of salt.
First, there is probably no active maintainer of the ARM build.
Second is as Kolcha discovered, it is not an easy task to make an universal build for this project, despite having the ARM and x86 builds separately. Itβll probably require many hours and probably some serious changes to implement.
Third is the lack of GitHub CI support. It is possible to cross-compile, but not possible to run test for ARM, unless you connect a M1 Mac to GitHub CI.
I for one am using the m1 build but it does slow down and hang sometimes.
The m1 builds are not problem free.
interesting, I haven't experienced that yet. I did make one change though... I set lib torrent to v2.0.4.0
I for one am using the m1 build but it does slow down and hang sometimes.
The m1 builds are not problem free.
If you're using the latest stable which I built, and having these problems, then probably it's my bad.
I used the Qt 5.15 branch and not the tag (5.15.2) to build that build. You can see that in the About section, where it'll tell you that 5.15.3 is the Qt version number.
I realized it only recently, and will publish a build later today, which built with the script and not by myself.
I just noticed it, that qBittorrent is actually using a patched version of libtorrent.
The version used for 4.3.9 is not 1.2.14, but 1.2.14+git28ebc27622.
It should be interpreted as 1.2.14 + commit 28ebc27622 as a patch, or 1.2.14 + everything until commit 28ebc27622?
I went with the later approach (aka everything until commit xyz) and generated the following builds with the slightly modified script (which cloning the git repo and checking out the commit hash with the submodules, instead of downloading the release version):
qBittorrent-release-4.3.9-macOS-arm64.dmg.zip (libtorrent 1.2.14+git28ebc27622)
qBittorrent-master-macOS-arm64.dmg.zip (libtorrent 2.0.4+git6717bd91a1)
I went with the later approach (aka everything until commit xyz) and generated the following builds with the slightly modified script (which cloning the git repo and checking out the commit hash with the submodules, instead of downloading the release version): qBittorrent-release-4.3.9-macOS-arm64.dmg.zip (libtorrent 1.2.14+git28ebc27622) qBittorrent-master-macOS-arm64.dmg.zip (libtorrent 2.0.4+git6717bd91a1)
Thanks for this new build. I've started using the release version (I cannot use the master one because some of the trackers I use ban master).
It seems that the issues I had with slow-downs and freezing are not happening anymore. I'll report back if I notice anything.
I went with the later approach (aka everything until commit xyz) and generated the following builds with the slightly modified script (which cloning the git repo and checking out the commit hash with the submodules, instead of downloading the release version): qBittorrent-release-4.3.9-macOS-arm64.dmg.zip (libtorrent 1.2.14+git28ebc27622) qBittorrent-master-macOS-arm64.dmg.zip (libtorrent 2.0.4+git6717bd91a1)
Is it possible to get a signed version? getting the following when trying to open the app "This software needs to be updated. Contact the developer for more information."
I went with the later approach (aka everything until commit xyz) and generated the following builds with the slightly modified script (which cloning the git repo and checking out the commit hash with the submodules, instead of downloading the release version): qBittorrent-release-4.3.9-macOS-arm64.dmg.zip (libtorrent 1.2.14+git28ebc27622) qBittorrent-master-macOS-arm64.dmg.zip (libtorrent 2.0.4+git6717bd91a1)
Is it possible to get a signed version? getting the following when trying to open the app "This software needs to be updated. Contact the developer for more information."
Go to System Preferences > Security & Privacy > General > select "Open Anyway"
I for one am using the m1 build but it does slow down and hang sometimes.
The m1 builds are not problem free.If you're using the latest stable which I built, and having these problems, then probably it's my bad. I used the Qt 5.15 branch and not the tag (5.15.2) to build that build. You can see that in the About section, where it'll tell you that 5.15.3 is the Qt version number. I realized it only recently, and will publish a build later today, which built with the script and not by myself.
It seems that Qt 5.15.3 fixed some UI bugs, look at these two pictures
no plans for a release ?
Any ideas when the M1 native version will be released? Many thanks
Unofficial qBittorrent 4.3.6 release for Apple M1
no any source code changes, ac8105c for Apple M1 only, NOT universal binary
compiled using slightly modified version of my script
P.S> very likely this is my last contribution regarding macOS. I sold my personal very old MacBook Pro, M1-based MacBook I have from work will also be given to another developer soon, so I will not have any Apple devices anymore. going back to Linux, like it was many years ago... and I'm very happy
@Kolcha Thank you very much for your compilation tutorial, but when I use new macbook pro with m1 pro chip and in macos12.1 system, I'm in a little troubleοΌ
According to your tutorial, will encounter a problem when compiling qt5
error: unknown type name 'CGColorSpaceRef'; did you mean 'QColorSpace'?
After searching the Internet, I found a solutionοΌ
https://code.qt.io/cgit/qt/qtbase.git/commit/src/plugins/platforms/cocoa?id=dece6f5840463ae2ddf927d65eb1b3680e34a547
edit ./qbt/src/qt5/qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h file
Add this line
#include <CoreGraphics/CGColorSpace.h>Then I finally compiled it successfully!
I hope this information is helpful to people who have the same environment as me
Unofficial qBittorrent 4.3.6 release for Apple M1
no any source code changes, ac8105c for Apple M1 only, NOT universal binary
compiled using slightly modified version of my script
P.S> very likely this is my last contribution regarding macOS. I sold my personal very old MacBook Pro, M1-based MacBook I have from work will also be given to another developer soon, so I will not have any Apple devices anymore. going back to Linux, like it was many years ago... and I'm very happy@Kolcha Thank you very much for your compilation tutorial, but when I use new macbook pro with m1 pro chip and in macos12.1 system, I'm in a little troubleοΌ According to your tutorial, will encounter a problem when compiling qt5
error: unknown type name 'CGColorSpaceRef'; did you mean 'QColorSpace'?
After searching the Internet, I found a solutionοΌ https://code.qt.io/cgit/qt/qtbase.git/commit/src/plugins/platforms/cocoa?id=dece6f5840463ae2ddf927d65eb1b3680e34a547 edit ./qbt/src/qt5/qtbase/src/plugins/platforms/cocoa/qiosurfacegraphicsbuffer.h file Add this line
#include <CoreGraphics/CGColorSpace.h>Then I finally compiled it successfully!
I hope this information is helpful to people who have the same environment as me
It is actually a XCode 13 related issue, so probably it is an issue on older machines too.
Here is the same fix in a git patch format:
https://gist.githubusercontent.com/R0GERIUS/a2d62e21995e732b9fe510efce71965d/raw/26e9f02b88d6eb41b3a6b636248d6290094ecdc9/qt5_xcode13.patch
In the coming days I'll try to publish the updated script too, which will include this fix and the ability to use commit hashes for some libraries.
on 4.3.9 release version.
sometimes i had to use force quit to close the app.
on 4.3.9 release version. sometimes i had to use force quit to close the app.
same
Unofficial qBittorrent 4.3.9 release for Apple M1
No source code changes, but the dependencies are updated to the newest stable versions.
The most important amongst them is the new libtorrent version (1.2.15), which contains 28ebc27622 fix (which were included in the official release, but for M1 you needed to modify the build script/procedure to include this fix).
This is for Apple M1 only, NOT universal binary!
Download qBittorrent 4.3.9 release for M1 here
Compiled using slightly modified version of @Kolcha's script.
The modifications of the script are the inclusion of XCode 13 Qt build fix and the ability to specify libtorrent commits for the build, so you're now able to build the 4.3.9 release with the specified dependencies.
I did not have the time to extensively test the build and the script itself, so please use these with caution and if you find errors in the script, please report them there.
P.S.: There is a bug with qBittorrent 4.3.9, where it always reports Boost 1.76.0, even if you used newer versions to build it (in this case Boost 1.78.0 was used).
on 4.3.9 release version.
sometimes i had to use force quit to close the app.
I encountered with this issue, but in my case waiting for a bit (less than 1 minute) solved this issue, so the application seems to be able to shut down, but it is slow.
I don't have any idea why, and we need to wait for a new stable or RC release to be able to guess whenever it is a dependency issue, or qBittorrent issue.
Unofficial qBittorrent 4.3.9 release for Apple M1
No source code changes, but the dependencies are updated to the newest stable versions. The most important amongst them is the new libtorrent version (1.2.15), which contains 28ebc27622 fix (which were included in the official release, but for M1 you needed to modify the build script/procedure to include this fix). This is for Apple M1 only, NOT universal binary!
Download qBittorrent 4.3.9 release for M1 here
Compiled using slightly modified version of @Kolcha's script. The modifications of the script are the inclusion of XCode 13 Qt build fix and the ability to specify libtorrent commits for the build, so you're now able to build the 4.3.9 release with the specified dependencies. I did not have the time to extensively test the build and the script itself, so please use these with caution and if you find errors in the script, please report them there.
P.S.: There is a bug with qBittorrent 4.3.9, where it always reports Boost 1.76.0, even if you used newer versions to build it (in this case Boost 1.78.0 was used).
Intersting thank you.
I'm wondering ,if it's stable (and it looks like it is,)will we finally see it in official releases? M1 has been sold for more than a year now ,i don't get why they don't release a stable M1 or even universal binary
Also dumb question but I already have an arm compatible qbittorrent release,however since it isn't official channel i cannot get in-app updates...if install yours do u think that's sth possible or do I have to check on GitHub every 2 days to see if a new release has been posted ?
Thanks!
I for one am using the m1 build but it does slow down and hang sometimes.
The m1 builds are not problem free.If you're using the latest stable which I built, and having these problems, then probably it's my bad. I used the Qt 5.15 branch and not the tag (5.15.2) to build that build. You can see that in the About section, where it'll tell you that 5.15.3 is the Qt version number. I realized it only recently, and will publish a build later today, which built with the script and not by myself.
It seems that Qt 5.15.3 fixed some UI bugs, look at these two pictures
Yeah, but sadly it's only on the master branch, which has no guarantee how stable it actually is...
It has 5.15.3 version, but with Qt it is not that easy, since officially 5.15.3 is a Commercial LTS release.
That means, the master branch was planned to be released as 5.15.3 as a Standard release at some point, but they changed the plans and that branch is probably abandoned.
The only hope for permanent UI fixes is the transition to Qt 6, because 5.15 Standard's development is probably non-existent at this point.
These are only my guesses, so take it with a grain of salt, but it is based on that the XCode 13 build issue is not addressed yet (and probably won't be fixed) and you need to apply 3rd party patches just to able even build Qt 5.15 latest stable.
Unofficial qBittorrent 4.3.9 release for Apple M1
No source code changes, but the dependencies are updated to the newest stable versions. The most important amongst them is the new libtorrent version (1.2.15), which contains 28ebc27622 fix (which were included in the official release, but for M1 you needed to modify the build script/procedure to include this fix). This is for Apple M1 only, NOT universal binary!
Download qBittorrent 4.3.9 release for M1 here
Compiled using slightly modified version of @Kolcha's script. The modifications of the script are the inclusion of XCode 13 Qt build fix and the ability to specify libtorrent commits for the build, so you're now able to build the 4.3.9 release with the specified dependencies. I did not have the time to extensively test the build and the script itself, so please use these with caution and if you find errors in the script, please report them there.
P.S.: There is a bug with qBittorrent 4.3.9, where it always reports Boost 1.76.0, even if you used newer versions to build it (in this case Boost 1.78.0 was used).Intersting thank you.
I'm wondering ,if it's stable (and it looks like it is,)will we finally see it in official releases? M1 has been sold for more than a year now ,i don't get why they don't release a stable M1 or even universal binary
Also dumb question but I already have an arm compatible qbittorrent release,however since it isn't official channel i cannot get in-app updates...if install yours do u think that's sth possible or do I have to check on GitHub every 2 days to see if a new release has been posted ?
Thanks!
This version is supposed to be stable and I'm using these builds myself too, however I'm a relatively lightweight torrent user.
That means I have no idea how stable it is in very heavy use-cases, but as a casual user I did not encounter any significant issue.
As for release standpoint: I am not qualified to answer, since I'm not responsible for this.
While iirc universal build won't happen in the near future, it can be released as a separate (ARM) build, however a maintainer/contributor need to actually look into this issue and do the required build system modifications and fixes if necessary.
About your second question: it isn't a dumb question, but it requires some off-topic things (which will be in the code block) to properly answer.
As an university student (still on BSc) I do lack of knowledge and the time which is necessary to implement such a system.
Tbh all of my knowledge about the building of this project's is originated from Kolcha's excellent build guide and script.
I do have some build system and Linux knowledge because of my earlier work experiences (I was working in DevOps as a student), but have no knowledge about any of the project's dependencies (since the projects connected to my DevOps jobs wasn't related to C++ and Qt at all).
That means, until the project has some build issues I may able to fix those, but if the problem is originated from the project's source code, all I can do is report those.
In short, while you'll sadly need to check this issue for updates, until this will be integrated to the main project, I'll only build the updates when it's necessary.
In this case the required commit was integrated as a 'hack' for the previous build, so I wanted to properly update this in order to address that and maybe address the shutdown issue.
However in the future I do only plan to build the release builds and maybe RC versions, when the project has a new release and only when nobody published a build by the time, when I built it.
(Which is basically running the script, which is linked above with some changed parameters.)
Would be really cool if you guys could try to build 4.4.0 with qt6, compiled for Apple Silicon.
Unofficial qBittorrent 4.4.0 releases for Apple M1
No source code changes, but since there are no new official 4.4.0 release for MacOS, I used libtorrent-rasterbar commit d0f7a09adb, which were used for the Linux and Windows versions.
This is for Apple M1 only, NOT universal binary!
Qt 5.15.2
qBittorrent-4.4.0-qt5.15.2-macOS-arm64.dmg.zip
Compiled using this script, (which is a slightly modified version of Kolcha's script) with the following parameters:
--qbittorrent=release-4.4.0 --libtorrent-commit=d0f7a09adb
Qt 6.2.2 - Crashing, please do not use this version!
qBittorrent-4.4.0-qt6.2.2-macOS-arm64.dmg.zip
Compiled using this script, which is a modified version of the previous one in order to be able to build Qt6.
The following parameters were used for the build: --qbittorrent=release-4.4.0 --libtorrent-commit=d0f7a09adb
Note: There is a Qt6 known issue: The text on the progress bar may have wrong color or not appear at all.
I encountered with this bug and in my case the progress bar is above the text (so it doesn't show after the bar reaches the text), until the progress bar reached 100%.
Here is how it looks like:
I did not have the time to extensively test the builds, so please use these with caution!
glad to see that my script written just for fun and out of curiosity was so useful and now is superseded!
just out of curiosity, I looked into new Qt6-based script version I was surprised to see some things there...
as I wrote before, I don't have Apple M1 based MacBook neither Intel-based personal MacBook, only pretty old Intel-based MacBook I got as my work laptop. fortunately due to my work specific, this work MacBook has suitable environment for building almost any C/C++ software. so, to build Qt 6 is not a problem and I decided to make few experiments.
after few Qt6 build tries I understood that it supports universal ("fat") binaries out of the box and this is the easiest way to do cross-compilation (which only is one way to get arm64 binaries in my case).
previously Qt5 libraries were the blocker to qBittorrent universal binary, with Qt6 this blocker gone. other required libraries even if can't be compiled into universal binaries, they are easy to "merge" into such one. so, I think to create the script (or just update existing to keep "host-only" or "cross-compilation" options available) which will be able to produce an universal binary (also I'll update build guide later).
so, there is my question: are universal builds interesting to someone?
glad to see that my script written just for fun and out of curiosity was so useful and now is superseded! just out of curiosity, I looked into new Qt6-based script version I was surprised to see some things there...
Yeah, tbf I was simply trying to make things work, but due the lack of knowledge regarding Qt builds, I basicaly tried out everything until it worked, while trying to leave most things as it is.
The only things which were necessary is removing one parameter (I donβt remember exactly which was, but it was related to compile examples), the environment variable pointing to the OpenSSL library, and changing make to cmake (make failed because the lack of target and Qt6 docs used cmake).
On my end without that variable the Qt configure was failing to detect the OpenSSL properly (At the configure results OpenSSL was yes, link was no, both OpenSSL variable was OFF for some reason, so the build failed with ERROR: βforcing openssl would breakβ¦β).
Also I published that script in a bit rough state just to show what exactly was used to build the Qt6 build above.
It was done mainly for two reason: I try to be open about what was used on order to avoid suspicion and if there is an issue with it, someone more experinced than me would be able to spot the issue easier, so it could be fixed faster.
It is entirely possible there were oversights when I removed all dead codes and experimental things. And I didnβt check all of the possible routes so there is a non-zero chance of bugs.
(And forgotten to properly fork it, so Iβm planning to fix that asap with changing the link on the post above and removing the current gist.)
so, there is my question: are universal builds interesting to someone?
I think yes, it would be interesting.
It would lead to less maintenance work, since it would be possible to unify the script for each architecture and it would be more user friendly on the long run.
I am also interested in how the build would look like for universal binaries and would gladly at least test the arm64 binaries of the universal builds.
so, there is my question: are universal builds interesting to someone?
Frankly I think they are interesting to everyone. Having to choose which CPU architecture you download sucks, especially for noobs who don't know what it means.
I was simply trying to make things work, but due the lack of knowledge regarding Qt builds
I'm too :) but I built Qt 4 and than Qt 5 for own purposes for very long time (~ since 2010), and it was even in wider configuration rather qBittorrent requires :) and have experience in building many very different C/C++ software on different platforms (but mostly Linux or Mac). maybe this experience just helped me to deal with Qt now, who knows... also I got first own qBittorrent builds very long time ago (in 2012), when it used Qt 4 and there were no Qt 4 Win64 builds...
Qt configure was failing to detect the OpenSSL properly
this is known and pretty common issue, especially when using cmake (some of mentioned "general mess"). but! in is not strictly necessary to build Qt with OpenSSL on macOS (even HTTPS communication using Qt' APIs is supposed) - on macOS Qt uses platform-specific APIs to provide secure communication. regarding qBittorrent itself, OpenSSL is mostly required for libtorrent, there are only few cases in app which use Qt' API for network communication. so, Qt can be safely build even without OpenSSL, but this is only on macOS.
I published that script in a bit rough state just to show what exactly was used to build the Qt6 build above
I didnβt check all of the possible routes so there is a non-zero chance of bugs
no one says that something is very bad n your script, and it is completely understandable that it may contain bugs and it was published "to be useful for someone". my script is also can not be called "perfect" :) and this is completely fine.
(And forgotten to properly fork it, so Iβm planning to fix that asap with changing the link on the post above and removing the current gist.)
it is nice to hear that you want to show from where this script comes from, but this is not strictly required, as you may notice, I didn't place any copyright message or even my name.
I think they are interesting to everyone. Having to choose which CPU architecture you download sucks
ok, wait for updates from me. will work on new script and manual these days (very likely updates appear only in a week).
especially for noobs who don't know what it means
don't think that such people come to places like GitHub when looking for software :) they are "true users" who just download software from market or other official and very easy to find places
especially for noobs who don't know what it means
don't think that such people come to places like GitHub when looking for software :) they are "true users" who just download software from market or other official and very easy to find places
There's no reason for the compiled binaries to only stay on GitHub, they should be used to make official universal binary releases when it's stable.
Would also love to see officially trusted Apple Silicon builds on the Qbittorrent site. How can I trust a .zip file that's just linked from one of these threads?
Would be fine to list it as an experimental build on the download page where we can at least trust the author. No need for universal, M1 only is fine if that is simpler.
Voice your support:
#16120
good news everyone! universal build was successfully got!
also I'll create another pretty detailed manual describing how to build this, like it previously for current available manual.
note: very likely script will be fine-tuned in few days after publication, planned changes should also affect producing binaries.
script was updated https://gist.github.com/Kolcha/3ccd533123b773ba110b8fd778b1c2bf
now it builds qBittorrent only with Qt6, Qt5 is not supported anymore, so it can be used only to build 4.4.x branch and newer.
by default (if target architecture is not specified) script produces binaries for architecture on each it was run.
to get universal binary -a universal must be passed.
a set of binaries (including universal) produced by this script can be downloaded here
any feedback about testing build script on Apple M1-based MacBook or compiled binaries itself is welcome.
Hi,
Thanks for updating the script! I just tested it out on my M1 iMac running macOS 12.1 with xCode 13.2.1 and got the following error:
Skipping optional dependency 'qtactiveqt' of 'qttools', because qtactiveqt's CMakeLists.txt couldn't be found.
Skipping optional dependency 'qtdeclarative' of 'qttools', because qtdeclarative's CMakeLists.txt couldn't be found.
Checking dependencies of 'qttranslations'
Configuring 'qtbase'
CMake Error at qtbase/CMakeLists.txt:22 (message):
The build path
"/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.XfwG2I08/build-universal/qt-6.2.2"
contains symlinks. This is not supported. Possible solutions:
- map directories using a transparent mechanism such as mount --bind
- pass the real path of the build directory to CMake, e.g. using cd
$(realpath <build_dir>) before invoking cmake <source_dir>.
-- Configuring incomplete, errors occurred!
See also "/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.XfwG2I08/build-universal/qt-6.2.2/CMakeFiles/CMakeOutput.log".
See also "/var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.XfwG2I08/build-universal/qt-6.2.2/CMakeFiles/CMakeError.log".
CMake Error at /var/folders/b4/kvmhwhw96kxgjp1w7922m6640000gn/T/tmp.XfwG2I08/src/qt-6.2.2/qtbase/cmake/QtProcessConfigureArgs.cmake:947 (message):
CMake exited with code 1.
@KwisatzJim , thanks for testing!
this error is very unexpected... don't know why, but Qt has the following code in CMakeLists.txt:
https://github.com/qt/qtbase/blob/eae95814a46386f8930eeae5486513a78a7a4ddc/CMakeLists.txt#L21-L27
/var directory is symlink on macOS, so that's why this error happened... I didn't test "default path" so didn't get this.
as solution, just pass -w <some dir> to the script, it should work.
I'll update the script later to avoid this ugly situation...
script updated, symlinks path issue mentioned above was fixed
script was updated https://gist.github.com/Kolcha/3ccd533123b773ba110b8fd778b1c2bf now it builds qBittorrent only with Qt6, Qt5 is not supported anymore, so it can be used only to build 4.4.x branch and newer. by default (if target architecture is not specified) script produces binaries for architecture on each it was run. to get universal binary
-a universalmust be passed.a set of binaries (including universal) produced by this script can be downloaded here
any feedback about testing build script on Apple M1-based MacBook or compiled binaries itself is welcome.
The script successfully built the 4.4.0 release tag as universal binary on my Macbook Air M1 too, and the arm64 binary runs completely fine at the moment.
I have one question though and that was why I included one more parameter option in my fork of the script: more often than not, it seems that the qBittorrent official builds using not the release, but newer than release version of libtorrent-rasterbar.
Currently they used for Windows and Linux the following version: 2.0.5+gitd0f7a09adb
I want to make sure I understand correctly, but how this version is supposed to be build? Simply cloning the mentioned commit (d0f7a09adb) from the repo (with the submodules), or there is an another trick?
official qBittorrent usually uses latest libtorrent commit at the moment of release. right now commits newer than official libtorrent 2.0.5 release are required to build with boost 1.78.0 (that's why I used 1.77.0).
the only one thing I don't know how qBittorrent devs build libtorrrent to get commit info in version number... at least some time ago I saw this in about dialog on Windows builds (I'm using Windows very very rarely to run qBittorrent on it).
in my cases, even build from git repo it includes just a version number, no commit info.
my script uses libtorrent release archives due to inability to download snapshot including required submodules. and I just don't want to clone whole repository - this is just a waste of space and time, even it is not so big. I don't see the reasons to use lastest commits from libtorrent.
to be able to build specific commit, just modify the script to clone repo and checkout to desired commit. or find a better way to get repo snapshot at specific commit including submodules.
Latest version of the script working great. Im having trouble figuring out the correct syntax for telling it a particular build. By default it's building 4.5.0-alpha for me. How do I get it to build release-4.4.0?