You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
🟦 Native Debian and Ubuntu cross build toolchains for cross compiling, used when a supported Debian based OS is the Host.
7
-
8
-
---
9
-
10
-
When building on supported Debian based hosts we use the official crossbuild-essential tool chains that are made specifically for cross compiling on these host operating systems.
11
-
12
-
On the modern distros like Bullseye and Jammy there is a wide range of supported cross build targets available.
13
-
14
-
:::caution
15
-
Only Bullseye and Jammy onwards have the full range of support we need to match the Alpine host options.
16
-
:::
17
-
18
-
Please look a the links below to see which options are available for which platform and release.
Ubuntu provides one additional package over Debian - `crossbuild-essential-riscv64`
26
-
:::
1
+
---
2
+
title: Debian Crossbuild-Essentials
3
+
hide_title: true
4
+
---
5
+
6
+
🟦 Native Debian and Ubuntu cross build toolchains for cross compiling, used when a supported Debian based OS is the Host.
7
+
8
+
---
9
+
10
+
When building on supported Debian based hosts we use the official `crossbuild-essential` tool chains that are made specifically for cross compiling on these host operating systems.
11
+
12
+
On the modern distros like Trixie and Noble there is a wide range of supported cross build targets available.
13
+
14
+
Please look a the links below to see which options are available for which platform and release.
🟦 Custom musl crossbuild toolchains based on [musl-cross-make](https://github.com/richfelker/musl-cross-make)
7
-
8
-
---
9
-
10
-
The main musl cross make is located here https://github.com/richfelker/musl-cross-make and the tools used here are derived from this.
11
-
12
-
[musl.cc](https://musl.cc) is a fork of the original mcm (musl cross make) project and they release and host cross toolchains to be used. The repo for the project is found here [https://git.zv.io/toolchains/musl-cross-make/-/tree/master](https://git.zv.io/toolchains/musl-cross-make/-/tree/master)
13
-
14
-
This project uses a hybrid version of the [musl.cc](https://musl.cc) musl cross make tool build tools and [musl.cc](https://github.com/richfelker/musl-cross-make) hosted on Github.
15
-
16
-
It uses newer current dependencies, is smaller in size and stays in sync with Alpine target architecture profiles.
17
-
18
-
The build process is automated via Github Actions. They can be found here https://github.com/userdocs/qbt-musl-cross-make
19
-
20
-
:::note
21
-
These are the tool chains used by this project to build static binaries on the Alpine Host, which is the default setup for the github releases.
22
-
:::
1
+
---
2
+
title: Musl Cross Make
3
+
hide_title: true
4
+
---
5
+
6
+
🟦 Custom musl crossbuild toolchains based on [musl-cross-make](https://github.com/richfelker/musl-cross-make)
7
+
8
+
---
9
+
10
+
The main musl cross make is located here https://github.com/richfelker/musl-cross-make and the tools used here are derived from this.
11
+
12
+
This project uses [qbt-musl-cross-make](https://github.com/userdocs/qbt-musl-cross-make)
13
+
14
+
Summary:
15
+
16
+
- It uses current build dependencies of `gcc` and `binutils`,
17
+
- It is optimized by buidl flags for toolchain and target
18
+
- focused on only `cc` and `c++` making for smaller toolchains
19
+
- Stays in sync with upstream Alpine target architecture profiles.
20
+
- Builds `static-pie` binaries.
21
+
- Provides prebuilt releases and docker images
22
+
23
+
The build process is fully automated via [Github Actions](https://github.com/userdocs/qbt-musl-cross-make/actions/workflows/ci-main-reusable-caller.yml).
Copy file name to clipboardExpand all lines: docs/src/content/docs/introduction.mdx
+38-33Lines changed: 38 additions & 33 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,13 +25,18 @@ import {
25
25
26
26
`qbt-nox-static.bash™` was originally a simple, amateurish bash script, to build a static `qbittorrent-nox` binary for `x86_64`. The script has grown and evolved since then and now it's a complicated bash script.
27
27
28
-
:::note
28
+
:::note[Current versions]
29
29
<ScriptVersions/>
30
+
:::
30
31
31
-
The former is a fork of the latter, from this version, with changes specific to the dependency handling, which in turn makes breaking changes to the default behavior of the script. Combined with renaming the script to `.bash` from `.sh` as it is not a POSIX compliant script this would effectively have made `qbittorrent-nox-static.sh` unavailable for use.
32
+
The former is a fork of the latter, with the following significant changes:
33
+
34
+
- Dependency-handling logic and data handling were heavily modified to allow more modular use of the script.
35
+
- This made breaking changes to the default behavior of the script and required user input.
36
+
- Combined with renaming the script to `.bash` from `.sh`, as it is not a POSIX-compliant script, this would have effectively made `qbittorrent-nox-static.sh` unavailable for use.
37
+
38
+
They are now essentially identical scripts, with `qbittorrent-nox-static.sh` having a small change to emulate the original behavior of the script to facilitate transition with no breaking changes.
32
39
33
-
So the existence of the two is a transitional change and the `qbt-nox-static.bash` will be deprecated in the future, though any non breaking changes will be backported to the original script.
34
-
:::
35
40
36
41
### Script version differences?
37
42
@@ -40,25 +45,23 @@ So the existence of the two is a transitional change and the `qbt-nox-static.bas
It will not do anything else unless prompted to do so and the required dependencies are present.
52
57
53
58
:::tip
54
-
With the minimum test dependencies installed, `git`,`bash` and `curl` it can perform most dynamic help functions and testing required to configure the script before installing the core dependencies.
59
+
With the minimum test dependencies installed, `git`,`bash`, and `curl` it can perform most dynamic help functions and testing required to configure the script before installing the core dependencies.
55
60
:::
56
61
57
62
So this allows for configuration to be done before installing core dependencies when the script is used interactively.
58
63
59
-
This makes sense when you consider you don't need to install host `gcc` to cross build, something which the script handles automatically when configured to cross build.
60
-
61
-
The logic of this is done using [bash associative arrays](https://www.gnu.org/software/bash/manual/html_node/Arrays.html).
64
+
This makes sense when you consider you don't need to install host `gcc` to cross-build, something the script handles automatically when configured to cross-build.
62
65
63
66
</TabItem>
64
67
<TabItemlabel="qbittorrent-nox-static.sh">
@@ -67,68 +70,70 @@ The logic of this is done using [bash associative arrays](https://www.gnu.org/so
67
70
68
71
When the script is run with no arguments and the required privileges are available it will attempt to automatically install the host dependencies if it can. It does this with no user input.
69
72
70
-
This is because it was designed to be used in a docker as root and not a normal host and interactive options came after.
73
+
When arguments are set that create dependency changes, the script will install them automatically when run.
74
+
75
+
This is because it was designed to be used in a Docker container as root, not on a normal host, and interactive options came later.
71
76
72
-
This raises a few concerns
77
+
This raises a few concerns:
73
78
74
-
- It means the env needs to be configured correctly or command passed before it is run for the first time to avoid unnecessary dependency installation.
79
+
- It means the environment needs to be configured correctly or commands passed before it is run for the first time to avoid unnecessary dependency installation.
75
80
- The behavior of installing dependencies without user interaction is undesirable.
76
81
- It was not clear to the end user what was happening without the required context.
77
82
78
-
If the host env if pre-configured this produces the desired result but if the user does not understand this and runs the script it will just be confusing to see it installing lots of things with no context.
79
-
80
-
The logic of this is done using [bash indexed arrays](https://www.gnu.org/software/bash/manual/html_node/Arrays.html).
83
+
If the host environment is pre-configured, this produces the desired result, but if the user does not understand this and runs the script, it will be confusing to see it installing many packages with no context.
81
84
82
85
:::note
83
-
If you are using the script for the first time use the `qbt-nox-static.bash` variant.
86
+
If you are using the script for the first time, use the `qbt-nox-static.bash` variant and follow the prompts.
84
87
:::
85
88
86
89
</TabItem>
87
90
</Tabs>
88
91
89
92
### What does it mean to you?
90
93
91
-
The documentation will be focused on `qbt-nox-static.bash` as it is the more sanely behaving script with a better user experience.
94
+
The documentation will be focused on `qbt-nox-static.bash` as it is the better-behaved script with a better user experience.
92
95
93
96
:::note
94
97
The binary outcome should be identical for both. You should use `qbt-nox-static.bash`, but if you understand how it works and are using Docker, `.qbt_env`, or a pre-configured environment, `qbittorrent-nox-static.sh` will do the same thing.
95
98
:::
96
99
97
100
## What does it do?
98
101
99
-
It handles a lot of the nuanced complexity around building various dependencies on two different host platforms toward the same outcome and can target these architectures via cross building:
102
+
It handles a lot of the nuanced complexity around building various dependencies on two different host platforms toward the same outcome and can target these architectures via cross-building:
103
+
104
+
Cross building is done by <Modalid="musl-cross-make"label="Musl Cross Make"/> on Alpine and <Modalid="crossbuild-essentials"label="Crossbuild Essentials"/> on Debian based.
100
105
101
-
<Detailssummary="target architectures">
102
-
`armel``armhf``armv7``aarch64`
106
+
<Detailssummary="target architectures">
107
+
`armel``armhf``armv7``aarch64`
103
108
104
-
`x86``x86_64`
109
+
`x86``x86_64`
105
110
106
-
`s390x`
111
+
`s390x`
107
112
108
-
`powerpc``ppc64el`
113
+
`powerpc``ppc64el`
109
114
110
-
`mips``mipsel``mips64``mips64el`
115
+
`mips``mipsel``mips64``mips64el`
111
116
112
117
`loongarch64`
113
118
114
-
`riscv64`
119
+
`riscv64`
115
120
</Details>
116
121
117
-
⭐ On supported host build platforms the `qbt-nox-static.bash` will perform these three main tasks via simple prompt:
122
+
⭐ On supported host build platforms, the `qbt-nox-static.bash` will perform these three main tasks via a simple prompt:
118
123
119
124
<Steps>
120
125
121
126
1. Update the system and install the core build dependencies, based on activated options - Requires `root` or `sudo` privileges if any dependencies are missing.
122
127
123
128
2. Download all dependencies locally and build `qbittorrent-nox` with no special privileges required.
124
129
125
-
3. Build a fully static and portable `qbittorrent-nox` binary which built using the latest version of all supported dependencies.
130
+
3. Build a fully static and portable `qbittorrent-nox` binary, which is built using the latest versions of all supported dependencies.
126
131
127
132
</Steps>
128
133
129
-
The script is highly configurable and is capable of native and crossbuilding. These more advanced configurations will be discussed later sections of the documentation.
134
+
The script is highly configurable and is capable of native and cross-building. These more advanced configurations will be discussed in later sections of the documentation.
130
135
131
-
## What is the outcome
136
+
## What is the outcome?
132
137
133
138
⭐ Here is an example successful default build profile:
134
139
@@ -173,8 +178,8 @@ statically linked
173
178
174
179
### How do I use it?
175
180
176
-
The script can be downloaded locally and run on a supported host or via docker. It has a comprehensive help section built in, available via the `-h` flag, that explains all options and demonstrates dynamic command choices. The best thing to do is read the script installation and usage sections to understand the key features and how to user them.
181
+
The script can be downloaded locally and run on a supported host or via Docker. It has a comprehensive built-in help section, available via the `-h` flag, that explains all options and demonstrates dynamic command choices. The best thing to do is read the script installation and usage sections to understand the key features and how to use them.
177
182
178
183
:::tip[The hard part is done.]
179
-
You always have a easy method available to you to build your own releases, simply by forking the repo and using the available workflows. How to do this will be shown in the <Modalid="github-actions"label="Github Actions"/> sections later on. You can build locally or fork the repo and build and release using CI where the git repo acts as a local environment to the script.
184
+
You always have an easy method available to build your own releases, simply by forking the repository and using the available workflows. How to do this will be shown in the <Modalid="github-actions"label="GitHub Actions"/> sections later on. You can build locally or fork the repository, and build and release using CI, where the Git repository acts as a local environment for the script.
Copy file name to clipboardExpand all lines: docs/src/content/docs/prerequisites.mdx
+12-2Lines changed: 12 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,10 +36,20 @@ If you want to self host you need to be able to meet these conditions on your ho
36
36
🟧 Host permissions
37
37
38
38
- The script needs to install some system dependencies in order to proceed and if you do not have permission or access to do this or no access to docker to use a container you must find a more suitable host environment.
39
+
- You can simply [fork the repo on Github](/qbittorrent-nox-static/github-actions) and create your own releases if you have no access to a suitable build host
39
40
40
-
🟥 Qt6 requirements
41
+
🟥 Emulation requirements for cross building
41
42
42
-
- If you build using Qt6 you will need to have these dependencies installed on the host (not inside the docker), <Modalid="qemu"label="qemu and binmtfs"/>
43
+
-`icu``qtbase` and `qttools` requires `qemu` emulation to be available by default in order to cross build them.
44
+
- This was reworked in script version `v2.2.2` and now the user has more choice of how to build.
45
+
- Two env vars specific to dealing with this were introduced
46
+
-`qbt_with_qemu` - this defaults to `yes` but if set to `no` if will enable `_host_deps` version of the modules that need a host version to be build before they can cross build.
47
+
- this means longer build times as these modules are essentially built twice.
48
+
-`qbt_host_deps` - defaults to `no` but if set to yes it will not build locally but instead pull in prebuilt host deps for the these modules avoiding the need to build them locally.
49
+
- They are built and sourced from here https://github.com/userdocs/qbt-host-deps
50
+
- This make build time equivalent to using `qemu` without the requirement of having `qemu`
51
+
52
+
If you build using Qt6 you will need to have these dependencies installed on the host (not inside the docker), <Modalid="qemu"label="qemu and binmtfs"/>
0 commit comments