Introduction

What is it?

qbittorrent-nox-static.sh™ 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.

What does it do?

It handles a lot of the nuanced complexity around building various different dependencies on two different host platforms, towards the same outcome, whilst targeting these architectures:

target architectures

aarch64 - armel - armhf - armv7

x86 - x86_64

powerpc - ppc64el

mips - mipsel - mips64 - mips64el

⭐ On supported host build platforms the qbittorrent-nox-static.sh will perform these three main tasks via simple prompt:

1. Update the system and install the core build dependencies, based on activated options - Requires root privileges if any dependencies are missing.

2. Download all dependencies locally and build qbittorrent-nox with no special privileges required.

3. Build a fully static and portable qbittorrent-nox binary which built useing the latest version of all supported dependencies.

The script is highly configurable and is capable of native and cross building. These more advanced configurations will be discussed later sections.

What is the outcome

⭐ Here is an example successful default build profile:

qBittorrent 4.6.4 was built with the following libraries:
Qt: 6.7.0
Libtorrent: 2.0.10
Boost: 1.84.0
OpenSSL: 3.3.0
zlib: 1.3.1.zlib-ng

Debian and Ubuntu Linux

The script creates a fully static qbittorrent-nox binary using glibc

The final result will show this when using ldd

ldd ~/qbt-build/bin/qbittorrent-nox

Gives this result:

not a dynamic executable

Alpine Linux

The script creates a fully static qbittorrent-nox binary using musl libc

The final result will show this when using ldd

ldd ~/qbt-build/bin/qbittorrent-nox

Gives this result:

statically linked

How do I use it?

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.

The hard part is done.

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