Question: Discrepancy in the built binary when libicu-dev is installed along with `libc6-dev` #10955

New issue

Open

opened 2026-02-21 21:03:39 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-21 21:03:39 -05:00

Owner

Originally created by @userdocs on GitHub (Sep 27, 2020).

Please provide the following information

qBittorrent version and Operating System

4.2.5 Debian based amd64

If on linux, libtorrent-rasterbar and Qt version

1.2.10

What is the problem

This is not a bug but an issue with qbittorrent as such but after exploring other support avenues it does appear to be related to development/compilation of the program and needs some insight from a dev perhaps?

When i am building qbittorrent-nox on a Linux (Debain based or Alpine) i am noticing a considerable size difference between the final static binary when libicu-dev is installed and certain dependencies are compiled locally. When statically built the filesize is 20M with libc6-dev vs 50M with libicu-dev.

In this example below I am using my partially static builds to demonstrate the issue. In this case files sizes are not relevant as the offending dependency is dynamically linked in qbittorrent but it does evidence the issue. Here is the build order for the locally compiled dependencies.

zlib > icu (skipped for this test) > openssl > boost_build > boost > qtbase > qttools  > libtorrent > qbittorrent

With just libc6-dev installed the result of ldd qbittorrent-build/completed/qbittorrent-nox is:

root@localhost:~# ldd qbittorrent-build-noicu/completed/noicu-qbittorrent-nox
        linux-vdso.so.1 (0x00007ffe54fc6000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc8d7db9000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc8d7db3000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc8d7bd2000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc8d7a83000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc8d7a68000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8d7876000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc8d9238000)

After libicu-dev is installed the result of ldd qbittorrent-build/completed/qbittorrent-nox is:

root@localhost:~# ldd qbittorrent-build-withicu/completed/withicu-qbittorrent-nox
        linux-vdso.so.1 (0x00007ffe1dab7000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f66fce72000)
        libicui18n.so.66 => /lib/x86_64-linux-gnu/libicui18n.so.66 (0x00007f66fcb73000)
        libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f66fc98d000)
        libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f66faecc000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f66faec6000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f66face5000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f66fab94000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f66fab79000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f66fa987000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f66fe27b000)

As you can see, the icu libraries are dynamically linked into the binary.

What is the point of this issue?

Ok, so the reason this is a problem or a poorly understood compilation issue is that at no point am I actually specifying a preference to include or use libicu-dev in my compilation. One or more of the dependencies are doing this via their configuration profiles and therefore choosing to use libicu-dev as a preference over iconv automatically if the libicu-dev package is installed.

For example when looking at the /include/QtCore/5.15.1/QtCore/private/qtcore-config_p.h (abbreviated to the relevant lines)

Without libicu-dev

#define QT_FEATURE_icu -1
#define QT_FEATURE_iconv 1

The configuration log:

Qt Core:
  iconv .................................. yes
  ICU .................................... no

With libicu-dev

#define QT_FEATURE_icu 1
#define QT_FEATURE_iconv -1

The configuration log:

Qt Core:
  iconv .................................. no
  ICU .................................... yes

In this particular case I believe both boost 1.74 and qtbase appear to prefer and use ICU if the libcu-dev is present. With possibly boost being the core offender of the size change but I am not 100% sure yet if it is one or both to blame

How can this resolved?

By understanding if there is a real value to including ICU as a dependency when two of the major dependencies will automatically prefer to use it if it is present and since it becomes linked to the qbittorrent binary itself. I would like the file size to be reduced but i cannot answer the question of whether it is better to include this dependency in the build chain or if it is peculiar coincidence with no change on the outcome, from a user/performance point of view. Hopefully someone can shed some light on the issue.

Examples:

Here are the build binaries for anyone who cares to to examine. Built Ubuntu 20.04

noicu-qbittorrent-nox.zip
withicu-qbittorrent-nox.zip

Originally created by @userdocs on GitHub (Sep 27, 2020). **Please provide the following information** ### qBittorrent version and Operating System 4.2.5 Debian based amd64 ### If on linux, libtorrent-rasterbar and Qt version 1.2.10 ### What is the problem This is not a bug but an issue with qbittorrent as such but after exploring other support avenues it does appear to be related to development/compilation of the program and needs some insight from a dev perhaps? When i am building qbittorrent-nox on a Linux (Debain based or Alpine) i am noticing a considerable size difference between the final static binary when `libicu-dev` is installed and certain dependencies are compiled locally. When statically built the filesize is 20M with `libc6-dev` vs 50M with `libicu-dev`. In this example below I am using my partially static builds to demonstrate the issue. In this case files sizes are not relevant as the offending dependency is dynamically linked in qbittorrent but it does evidence the issue. Here is the build order for the locally compiled dependencies. ``` zlib > icu (skipped for this test) > openssl > boost_build > boost > qtbase > qttools > libtorrent > qbittorrent ``` With just `libc6-dev` installed the result of `ldd qbittorrent-build/completed/qbittorrent-nox` is: ``` root@localhost:~# ldd qbittorrent-build-noicu/completed/noicu-qbittorrent-nox linux-vdso.so.1 (0x00007ffe54fc6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc8d7db9000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc8d7db3000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc8d7bd2000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc8d7a83000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc8d7a68000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8d7876000) /lib64/ld-linux-x86-64.so.2 (0x00007fc8d9238000) ``` After `libicu-dev` is installed the result of `ldd qbittorrent-build/completed/qbittorrent-nox` is: ``` root@localhost:~# ldd qbittorrent-build-withicu/completed/withicu-qbittorrent-nox linux-vdso.so.1 (0x00007ffe1dab7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f66fce72000) libicui18n.so.66 => /lib/x86_64-linux-gnu/libicui18n.so.66 (0x00007f66fcb73000) libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f66fc98d000) libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f66faecc000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f66faec6000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f66face5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f66fab94000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f66fab79000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f66fa987000) /lib64/ld-linux-x86-64.so.2 (0x00007f66fe27b000) ``` As you can see, the icu libraries are dynamically linked into the binary. What is the point of this issue? Ok, so the reason this is a problem or a poorly understood compilation issue is that at no point am I actually specifying a preference to include or use `libicu-dev` in my compilation. One or more of the dependencies are doing this via their configuration profiles and therefore choosing to use `libicu-dev` as a preference over iconv automatically if the `libicu-dev` package is installed. For example when looking at the `/include/QtCore/5.15.1/QtCore/private/qtcore-config_p.h` (abbreviated to the relevant lines) Without `libicu-dev` ``` #define QT_FEATURE_icu -1 #define QT_FEATURE_iconv 1 ``` The configuration log: ``` Qt Core: iconv .................................. yes ICU .................................... no ``` With `libicu-dev` ``` #define QT_FEATURE_icu 1 #define QT_FEATURE_iconv -1 ``` The configuration log: ``` Qt Core: iconv .................................. no ICU .................................... yes ``` In this particular case I believe both boost 1.74 and qtbase appear to prefer and use ICU if the `libcu-dev` is present. With possibly boost being the core offender of the size change but I am not 100% sure yet if it is one or both to blame ### How can this resolved? By understanding if there is a real value to including ICU as a dependency when two of the major dependencies will automatically prefer to use it if it is present and since it becomes linked to the qbittorrent binary itself. I would like the file size to be reduced but i cannot answer the question of whether it is better to include this dependency in the build chain or if it is peculiar coincidence with no change on the outcome, from a user/performance point of view. Hopefully someone can shed some light on the issue. ### Examples: Here are the build binaries for anyone who cares to to examine. Built Ubuntu 20.04 [noicu-qbittorrent-nox.zip](https://github.com/qbittorrent/qBittorrent/files/5289085/noicu-qbittorrent-nox.zip) [withicu-qbittorrent-nox.zip](https://github.com/qbittorrent/qBittorrent/files/5289086/withicu-qbittorrent-nox.zip)