Executable on Linux always so large, why?
-
When creating an installer on linux for a Qt app, the installer executable created are always big (around 58MiB) don't matter how small is the app created and that because of the .so that goes together with the executable.
I am wondering if there's a way to avoid this or always when creating an installer for a Qt app on linux the resulting installer executable will be that big.
-
When creating an installer on linux for a Qt app, the installer executable created are always big (around 58MiB) don't matter how small is the app created and that because of the .so that goes together with the executable.
I am wondering if there's a way to avoid this or always when creating an installer for a Qt app on linux the resulting installer executable will be that big.
@hbatalha said in Executable on Linux always so large, why?:
When creating an installer on linux for a Qt app, the installer executable created are always big (around 58MiB)
You didn't tell us which installer software you used.
Some possibilities are:
-
(e.g. The Qt Installer Framework) The installer executable depends on some libraries, and it uses static linking instead of dynamic linking. Static linking embeds the libraries into the executable itself; this means that the user can run the executable even if the libraries are not found on the PC, but of course embedding libraries will dramatically increase executable size.
-
(e.g. AppImage, Snap, or Flatpak) The installer is actually a self-contained bundle. It contains your app plus all the libraries that your app depends on.
-
-
@hbatalha said in Executable on Linux always so large, why?:
When creating an installer on linux for a Qt app, the installer executable created are always big (around 58MiB)
You didn't tell us which installer software you used.
Some possibilities are:
-
(e.g. The Qt Installer Framework) The installer executable depends on some libraries, and it uses static linking instead of dynamic linking. Static linking embeds the libraries into the executable itself; this means that the user can run the executable even if the libraries are not found on the PC, but of course embedding libraries will dramatically increase executable size.
-
(e.g. AppImage, Snap, or Flatpak) The installer is actually a self-contained bundle. It contains your app plus all the libraries that your app depends on.
@JKSH said in Executable on Linux always so large, why?:
You didn't tell us which installer software you used.
I used Qt Installer Framework, binarycreator.
I read somewhere that to build static apps with Qt you will have to build Qt statically and then build first/
-
-
@JKSH said in Executable on Linux always so large, why?:
You didn't tell us which installer software you used.
I used Qt Installer Framework, binarycreator.
I read somewhere that to build static apps with Qt you will have to build Qt statically and then build first/
@hbatalha said in Executable on Linux always so large, why?:
I read somewhere that to build static apps with Qt you will have to build Qt statically and then build first
The Qt Installer Frame uses static linking for the installer executable.
Your app executable does not need to use static linking.
-
@hbatalha said in Executable on Linux always so large, why?:
I read somewhere that to build static apps with Qt you will have to build Qt statically and then build first
The Qt Installer Frame uses static linking for the installer executable.
Your app executable does not need to use static linking.
-
@JKSH Then I am not configuring it right because mine is static, it install the program into a folder containing the executable together with all the .so files
@hbatalha said in Executable on Linux always so large, why?:
Then I am not configuring it right because mine is static, it install the program into a folder containing the executable together with all the .so files
This issue has nothing to do with the installer; binarycreator simply copies the files that you tell it to copy; it doesn't link your libraries to your app.
Please open a new thread to discuss static linking your application.
-
@JKSH Then I am not configuring it right because mine is static, it install the program into a folder containing the executable together with all the .so files
@hbatalha said in Executable on Linux always so large, why?:
Then I am not configuring it right because mine is static, it install the program into a folder containing the executable together with all the .so files
If you have a lot of shared libraries (the .so files) for Qt libraries then you probably have a dynamically linked Qt application.
If your application was statically linked then the application executable would be a single, large binary that contained the relevant parts of the Qt libraries internally. There may be a couple of associated 3rd party shared libraries (perhaps for ICU). You have to go out of your way to make a Qt library set that supports being statically linked: it's not something you do accidentally.
As for the size problem:
- Ensure you are shipping release libraries that have been stripped with your release build application. Debugging information can be bulky.
- Ensure you are not shipping Qt libraries your application is not using. E.g. Qt5 Qml is not needed if you are not using QML, and Qt5 WebEngine is huge.
- If you know the target environment then you might be able to omit libraries like ICU because a compatible version is already present.
- You may be able to use something like UPX to compress the executable
-
@hbatalha said in Executable on Linux always so large, why?:
Then I am not configuring it right because mine is static, it install the program into a folder containing the executable together with all the .so files
If you have a lot of shared libraries (the .so files) for Qt libraries then you probably have a dynamically linked Qt application.
If your application was statically linked then the application executable would be a single, large binary that contained the relevant parts of the Qt libraries internally. There may be a couple of associated 3rd party shared libraries (perhaps for ICU). You have to go out of your way to make a Qt library set that supports being statically linked: it's not something you do accidentally.
As for the size problem:
- Ensure you are shipping release libraries that have been stripped with your release build application. Debugging information can be bulky.
- Ensure you are not shipping Qt libraries your application is not using. E.g. Qt5 Qml is not needed if you are not using QML, and Qt5 WebEngine is huge.
- If you know the target environment then you might be able to omit libraries like ICU because a compatible version is already present.
- You may be able to use something like UPX to compress the executable
You have to go out of your way to make a Qt library set that supports being statically linked: it's not something you do accidentally.
Is any there any change that the resulting executable will be smaller smaller.
Ensure you are not shipping Qt libraries your application is not using. E.g. Qt5 Qml is not needed if you are not using QML, and Qt5 WebEngine is huge.
The ones that are pretty huge(25MiB each) are libicudata.so.56.1 and libicudata.so.56.
You may be able to use something like UPX to compress the executable
Thanks, that helped a lot
-
@hbatalha said in Executable on Linux always so large, why?:
libicudata.so.56.1 and libicudata.so.56.
These are the same file;
libicudata.soandlibicudata.so.56are links to the actual filelibicudata.so.56.1.
You only need to ship one$ ls -l libicudat* lrwxrwxrwx 1 chrisw chrisw 18 Jun 8 2020 libicudata.so -> libicudata.so.56.1 lrwxrwxrwx 1 chrisw chrisw 18 Jun 8 2020 libicudata.so.56 -> libicudata.so.56.1 -rwxr-xr-x 1 chrisw chrisw 25048256 Sep 26 2016 libicudata.so.56.1This mechanism is used to cater for a program that can function with any ICU (links to
libicudata.so), needs any ICU at version 56 (links tolibicudata.so.56), or specifically needs 56.1. Runlddagainst your compiled application to see what it links to (probablylibicudata.so.56). -
@hbatalha said in Executable on Linux always so large, why?:
libicudata.so.56.1 and libicudata.so.56.
These are the same file;
libicudata.soandlibicudata.so.56are links to the actual filelibicudata.so.56.1.
You only need to ship one$ ls -l libicudat* lrwxrwxrwx 1 chrisw chrisw 18 Jun 8 2020 libicudata.so -> libicudata.so.56.1 lrwxrwxrwx 1 chrisw chrisw 18 Jun 8 2020 libicudata.so.56 -> libicudata.so.56.1 -rwxr-xr-x 1 chrisw chrisw 25048256 Sep 26 2016 libicudata.so.56.1This mechanism is used to cater for a program that can function with any ICU (links to
libicudata.so), needs any ICU at version 56 (links tolibicudata.so.56), or specifically needs 56.1. Runlddagainst your compiled application to see what it links to (probablylibicudata.so.56).
