Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Static binaries are too big #2
Hmmm, I just realised something. I reported in previous issue:
that I successfully compiled 'i386-uclibc-gcc'. I tested with a simple hello world:
Compile and strip:
Before stripping, size is 276K, after stripping is 262K!!!
I have gcc 6.3.0, binutils 2.28.
It should be about 17K stripped, that's the size which I get with
I am far from expert at this, but compiled hello.c with gcc and uclibc directly:
Still get 262KB after stripping. Tried sstrip also, got it down to 261KB!
I googled around, and found this post:
... 107K and growing! It is still better than 600K+ with glibc, however, if this is true, then uclibc-ng has gone to the dogs. The main usage, for me anyway, is to produce small executables.
Looks like I am going back to musl.
Had to find out what is going on here! I compiled the latest uclibc from git (NOT uclibc-ng), last commit was in 2015, added some patches from the T2-project, used it to compile 'hello.c' --- aargh, got 254K stripped.
So, looked into the .config file. Locale support is turned on, with support for all locales. I changed that to just support "en_US", this time 'hello' is 102K not stripped, 86K stripped.
Very interesting, that all the locale data is builtin to the binary.
86K is still high, so will experiment some more with the .config file. But it sure does beat 650K with glibc!
This issue can be closed.
To round off this issue, a bit more info.
By disabling locale support, testing with uclibc-ng, got Hello World down to 56K. See comment here:
There are other features, I think iconv support is one, if enabled, get into the static executable whether used or not. I reckon this rates as a bug.
Thank you for investigating binary bloat when linking with newer versions of uClibc and uclibc-ng.
However, large binary sizes with uclibc-ng shouldn't be considered a bug of pts-tcc, thus I've labeled this issue as question. Feel free to report this as a bug to the uclibc-ng maintainers.
Please note that pts-tcc was designed to be used with uClibc 0.9.30.1 (from 2009).
It may be interesting to upgrade pts-tcc to use uClibc 0.9.33.2 (from 2012, the last uClibc release) and check file sizes. If you feel like doing so, please create a separate issue for that.
Thank you for reporting this!
Now https://github.com/pts/pts-tcc/blob/master/pts-tcc-0.9.26-compile.sh uses a specific, hardcoded version of precompiled uClibc which doesn't have the binary bloat you are experiencing with uclibc-ng.
I'm closing this issue now since I can't see how pts-tcc can be improved in this aspect. Feel free to open new issues if you encounter anything.