On 09/28/2014 01:44 AM, Jorge Almeida wrote:
> I'm having a somewhat disgusting issue on my Gentoo: binaries are
> unaccountably large.
> 
> I'm talking about C programs of my own, so no version related issues
> whatsoever. The computer is a core i3 with a 32 bit system.
> 
> Example, for the same program:
> 
> 10275 B on an atom running Slackware 14.1 (gcc 4.8.2)
> 5896 B (same, stripped with strip --strip-unneeded)
> 
> 11675 B on i3, Gentoo, gcc 4.8.3 (with default gcc it was worse)
> 9704 B stripped
> 
> 8207 B on *the same i3 box* running LFS (gcc 4.9.1)
> 5768 B stripped
> 
> When compiling against dietlibc, the difference is even more shocking
> (almost double size in Gentoo after stripping).
> 
> Compiled with:
> gcc -Os -march=i686  -fomit-frame-pointer -pipe -Wall -pedantic
> -fdata-sections -ffunction-sections -Wl,--gc-sections
> -fno-asynchronous-unwind-tables -std=c99
> 
> Gentoo:
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.8.3/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.8.3/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with:
> /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure
> --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr
> --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.8.3
> --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include
> --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3
> --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3/man
> --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.8.3/info
> --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.8.3/include/g++-v4
> --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.8.3/python
> --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
> --disable-werror --with-system-zlib --disable-nls
> --enable-checking=release --with-bugurl=https://bugs.gentoo.org/
> --with-pkgversion='Gentoo 4.8.3' --enable-libstdcxx-time
> --enable-shared --enable-threads=posix --enable-__cxa_atexit
> --enable-clocale=gnu --disable-multilib --disable-altivec
> --disable-fixed-point --with-arch=i686 --enable-targets=all
> --disable-libgcj --enable-libgomp --disable-libmudflap
> --disable-libssp --enable-lto --without-cloog
> Thread model: posix
> gcc version 4.8.3 (Gentoo 4.8.3)
> 
> LFS:
> ##  gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.9.1/lto-wrapper
> Target: i686-pc-linux-gnu
> Configured with: ../gcc-4.9.1/configure --prefix=/usr
> --enable-languages=c,c++ --disable-multilib --disable-bootstrap
> --with-system-zlib
> Thread model: posix
> gcc version 4.9.1 (GCC)
> 
> Slackware:
> Reading specs from /slash/usr/bin/../lib/gcc/i486-slackware-linux/4.8.2/specs
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/slash/usr/bin/../libexec/gcc/i486-slackware-linux/4.8.2/lto-wrapper
> Target: i486-slackware-linux
> Configured with: ../gcc-4.8.2/configure --prefix=/usr
> --libdir=/usr/lib --mandir=/usr/man --infodir=/usr/info
> --enable-shared --enable-bootstrap
> --enable-languages=ada,c,c++,fortran,go,java,lto,objc
> --enable-threads=p osix --enable-checking=release --enable-objc-gc
> --with-system-zlib --with-python-dir=/lib/python2.7/site-packages
> --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
> --enable-lto --with-gnu-ld --verbose --enable-java-home
> --with-java-home=/usr/lib/jvm/jre --with-jvm-root-dir=/usr/lib/jvm
> --with-jvm-jar-dir=/usr/lib/jvm/jvm-exports --with-arch-directory=i386
> --with-antlr-jar=/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar
> --enable-java-awt=gtk --disable-gtktest --with-arch=i486
> --target=i486-slackware-linux --build=i486-slackware-linux
> --host=i486-slackware-linux
> Thread model: posix
> gcc version 4.8.2 (GCC)
> 
> I'm not elfwise, but I could post something to google drive if needed.

Are you cross-compiling for different hardware?  I'm just curious what results
you get with --march=native.

Also, I looked up data-sections and function-sections (which I'd never heard
of before today :)  The gcc man page says the resulting executable will be
larger and slower, and not to use them "unless there are significant benefits"
but then doesn't say what those benefits might be. Hm, cryptic.


Reply via email to