Closed adi1382 closed 2 years ago
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 ab6141edb7fd67ab0037f642eacb7ce89907b8f5 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...
compiled using the same libraries versions as official no any source code changes, 332b173e080aa2deb2933eb848298fd98b71514b 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...
@Kolcha
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.
no any source code changes, 063844ed44bffd3fbf2ac2792590ba47bf3fb78e 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 :)
@Kolcha
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.
@FranciscoPombal
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
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 :)
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.
no any source code changes, ac8105c304b84c77b7b72fbf4547e7ad977d44fc 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.Beta1
how 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
,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
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.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
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.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
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.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
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.zip
tq 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 : https://github.com/Homebrew/homebrew-core/commit/80e3dc7af2e363e9c50cdac8d69a27540c526eb6 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/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.
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
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?