Re: [gentoo-user] bloated by gcc
On Sun, Sep 28, 2014 at 09:44:16AM +0100, 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 In my make.conf I have... CFLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-unwind-tables is the extra flag I have that you don't have. See http://comments.gmane.org/gmane.linux.busybox/36695 for a short discussion .eh_frame bloat issue - solution found. The busybox people go to extreme lengths to keep the size of busybox to a minimum, so you can't go wrong by following their example. I assume that you do not have debugging enabled. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 12:18 PM, Walter Dnes waltd...@waltdnes.org wrote: On Sun, Sep 28, 2014 at 09:44:16AM +0100, Jorge Almeida wrote I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. -fno-unwind-tables is the extra flag I have that you don't have. See http://comments.gmane.org/gmane.linux.busybox/36695 for a short discussion .eh_frame bloat issue - solution found. The busybox people go to extreme lengths to keep the size of busybox to a minimum, so you can't go wrong by following their example. I assume that you do not have debugging enabled. Just tried it, no difference. The point is that the same flags should yield similar results, and I'm getting the worst results on my Gentoo system. I don't run desktop environments; I run useful applications +1, BTW...
Re: [gentoo-user] bloated by gcc
Am 28.09.2014 10:44, schrieb Jorge Almeida: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Really? Who cares. Storage is so cheap nowadays, that that kind of bloat simply doesn't matter on normal deskop computers anymore. Embedded systems though are a different cup of coffee.
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 3:50 PM, Marc Stürmer m...@marc-stuermer.de wrote: Am 28.09.2014 10:44, schrieb Jorge Almeida: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Really? Who cares. Storage is so cheap nowadays, that that kind of bloat simply doesn't matter on normal deskop computers anymore. Embedded systems though are a different cup of coffee. I care, that's why I wrote to this list. What I don't care about is your opinions, no more than you care about mine. Feel free to start a thread about whatever you find important/interesting/cool/shining/modern. Bye.
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 12:45:44PM +0100, Jorge Almeida wrote Just tried it, no difference. The point is that the same flags should yield similar results, and I'm getting the worst results on my Gentoo system. Grasping at straws now. What are your CFLAGS and full USE flags? I suggest running the command... emerge --info | grep ^\(CFLAGS\|USE\) This captures default USE flags that aren't explicitly listed in your make.conf. Out of sheer curiusity, what sizes do you get if you use -O2? I believe that turns off loop-unrolling. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] bloated by gcc
On 29/09/2014 16:10, Jorge Almeida wrote: On Mon, Sep 29, 2014 at 3:50 PM, Marc Stürmer m...@marc-stuermer.de wrote: Am 28.09.2014 10:44, schrieb Jorge Almeida: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Really? Who cares. Storage is so cheap nowadays, that that kind of bloat simply doesn't matter on normal deskop computers anymore. Embedded systems though are a different cup of coffee. I care, that's why I wrote to this list. What I don't care about is your opinions, no more than you care about mine. Feel free to start a thread about whatever you find important/interesting/cool/shining/modern. Bye. You might consider making contact with the toolchain herd at gentoo or filing a bug. I, for one, would be interested to know the outcome. --Kerin
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 4:15 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Sep 29, 2014 at 12:45:44PM +0100, Jorge Almeida wrote Grasping at straws now. What are your CFLAGS and full USE flags? I suggest running the command... emerge --info | grep ^\(CFLAGS\|USE\) This captures default USE flags that aren't explicitly listed in your make.conf. Out of sheer curiusity, what sizes do you get if you use -O2? I believe that turns off loop-unrolling. No difference with -O2. The program I'm using (as test) is really simple (a terminal wall clock), although the same problem happens with other programs. Are the USE flags relevant for a program that is orthogonal to emerge? Anyway, here it goes: # emerge --info | grep ^\(CFLAGS\|USE\) CFLAGS=-O2 -march=native -pipe -fomit-frame-pointer USE=berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv modules ncurses nptl openmp pcre readline session ssl unicode x86 zlib ABI_X86=32 ALSA_CARDS=ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci APACHE2_MODULES=authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias CALLIGRA_FEATURES=kexi words flow plan sheets stage tables krita karbon braindump author CAMERAS=ptp2 COLLECTD_PLUGINS=df interface irq load memory rrdtool swap syslog ELIBC=glibc GPSD_PROTOCOLS=ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx GRUB_PLATFORMS=efi-32 INPUT_DEVICES=keyboard mouse evdev KERNEL=linux LCD_DEVICES=bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text LIBREOFFICE_EXTENSIONS=presenter-console presenter-minimizer OFFICE_IMPLEMENTATION=libreoffice PHP_TARGETS=php5-5 PYTHON_SINGLE_TARGET=python2_7 PYTHON_TARGETS=python2_7 python3_3 RUBY_TARGETS=ruby19 ruby20 USERLAND=GNU VIDEO_CARDS=fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l XTABLES_ADDONS=quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account gcc has CFLAGS=-O2 -march=i686 -pipe, via /etc/portage/env thanks Jorge
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 12:02 PM, Jorge Almeida jjalme...@gmail.com wrote: On Mon, Sep 29, 2014 at 4:25 PM, Kerin Millar kerfra...@fastmail.co.uk wrote: On 29/09/2014 16:10, Jorge Almeida wrote: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. You might consider making contact with the toolchain herd at gentoo or filing a bug. I, for one, would be interested to know the outcome. Well, I suppose this one is the list every gentooer subscribes to, and I would like to be sure I'm not making something silly before filing a bug... Meanwhile, I tried compiling with clang. It produces similar sizes in Gentoo and in LFS (same i3 computer), although about 200B larger than in Slackware/atom. So, it really seems to be a gcc issue. thanks Jorge Just the off the top of my head thoughts on how I'd approach this. GCC has the option to not clean up its temp files used during the build, as well as outputting annotated assembly mid-build. The latter might be the most enlightening on what's being treated differently in the output of the various systems. I don't use those tricks often enough to remember what flags are what off the top of my head, since I only really dig that deep when playing with my avr based toys, but just a couple ideas I thought I'd pass along. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 4:25 PM, Kerin Millar kerfra...@fastmail.co.uk wrote: On 29/09/2014 16:10, Jorge Almeida wrote: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. You might consider making contact with the toolchain herd at gentoo or filing a bug. I, for one, would be interested to know the outcome. Well, I suppose this one is the list every gentooer subscribes to, and I would like to be sure I'm not making something silly before filing a bug... Meanwhile, I tried compiling with clang. It produces similar sizes in Gentoo and in LFS (same i3 computer), although about 200B larger than in Slackware/atom. So, it really seems to be a gcc issue. thanks Jorge
Re: [gentoo-user] bloated by gcc
Am 28.09.2014 um 10:44 schrieb Jorge Almeida: 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=posix --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. TIA Jorge Almeida Hi :) I have compared some exes and libs from Ubuntu 14.04 and my Gentoo (both x86_64) and for similar versions it seems like most of _my_ Gentoo binaries are around 10% bigger (a few are 10% smaller). I have completely ignored GCC settings (both are 4.8.x though). IMO your sample (one 5-10 kb program) is not representative for the distro in general. I compared: /bin/bash /usr/bin/xterm /bin/bzip2 /bin/gzip /usr/bin/xz /usr/bin/xev /usr/lib/libaspell.so /usr/lib/libdaemon.so IMO you shouldn't compare 4.8.x with 4.9.x. I don't want to dismiss your concern with your specific program. In your case it is a big difference, and I'm curios too, where it comes from. Maybe you can find out more by a more thorough comparation of the flags GCC uses at runtime by comparing the output of: gcc -Q your flags (w/o -pipe) --help=target gcc -Q your flags (w/o -pipe) --help=optimizers (Find more --help= in the man page.) Greetings Daniel -- Get my PGP key at: * http://keyserver.ubuntu.com:11371/pks/lookup?op=getsearch=0x837FB8B5BB9D4887 * $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 10:50 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 28.09.2014 10:44, schrieb Jorge Almeida: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Really? Who cares. Storage is so cheap nowadays, that that kind of bloat simply doesn't matter on normal deskop computers anymore. Embedded systems though are a different cup of coffee. I think it would be useful to actually understand what is going on here, assuming it isn't a mistake of some kind. And storage isn't as cheap as some make it out to be. Sure, spinning disks are pretty cheap, but embedded systems are always constrained, SSDs aren't so cheap, and in-RAM space used by a binary is always a concern. Even if you have plenty of system RAM, excessive RAM use by a binary means poor processor cache utilization. L1/L2 cache is still measured in kilobytes to this day, and L3 is measured in MB. Besides, if we don't actually know why there is a difference there is no way to know that the compiler isn't doing more than just waste memory. -- Rich
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 5:35 PM, Daniel Troeder dan...@admin-box.com wrote: Am 28.09.2014 um 10:44 schrieb Jorge Almeida: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Jorge Almeida Hi :) Hi, thanks for replying. I have compared some exes and libs from Ubuntu 14.04 and my Gentoo (both x86_64) and for similar versions it seems like most of _my_ Gentoo binaries are around 10% bigger (a few are 10% smaller). I have completely ignored GCC settings (both are 4.8.x though). IMO your sample (one 5-10 kb program) is not representative for the distro in general. Actually, I didn't even thought of comparing sizes of the distros binaries (the ones that are produced by emerging). My programs were first compiled against dietlibc (where I noticed the size difference), so they do not depend on USE variables nor CFLAGS. And glibc is not the culprit. Maybe gcc, unless it is binutils, or who knows... But if bash etc is bigger than in other distros (or not), that's fine by me, the devs sure know better than I. IMO you shouldn't compare 4.8.x with 4.9.x. My atom (Slackware) has gcc 4.8.2, Gentoo had 4.7.3. I emerged 4.8.3 (~x86) because with 4.7.3 it was even worse! I don't want to dismiss your concern with your specific program. In your case it is a big difference, and I'm curios too, where it comes from. Maybe you can find out more by a more thorough comparation of the flags GCC uses at runtime by comparing the output of: gcc -Q your flags (w/o -pipe) --help=target gcc -Q your flags (w/o -pipe) --help=optimizers Thanks for the suggestion. I'll look at it carefully. Jorge
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 5:20 PM, Poison BL. poiso...@gmail.com wrote: On Mon, Sep 29, 2014 at 12:02 PM, Jorge Almeida jjalme...@gmail.com wrote: I'm having a somewhat disgusting issue on my Gentoo: binaries are unaccountably large. Just the off the top of my head thoughts on how I'd approach this. GCC has the option to not clean up its temp files used during the build, as well as outputting annotated assembly mid-build. The latter might be the most enlightening on what's being treated differently in the output of the various systems. I don't use those tricks often enough to remember what flags are what off the top of my head, since I only really dig that deep when playing with my avr based toys, but just a couple ideas I thought I'd pass along. Thanks, but interpreting the output is way above my skills. I'll try the suggestion of Daniel first. Jorge
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 04:32:40PM +0100, Jorge Almeida wrote On Mon, Sep 29, 2014 at 4:15 PM, Walter Dnes waltd...@waltdnes.org wrote: On Mon, Sep 29, 2014 at 12:45:44PM +0100, Jorge Almeida wrote Grasping at straws now. What are your CFLAGS and full USE flags? I suggest running the command... emerge --info | grep ^\(CFLAGS\|USE\) This captures default USE flags that aren't explicitly listed in your make.conf. Out of sheer curiusity, what sizes do you get if you use -O2? I believe that turns off loop-unrolling. No difference with -O2. The program I'm using (as test) is really simple (a terminal wall clock), although the same problem happens with other programs. Are the USE flags relevant for a program that is orthogonal to emerge? Probably not. Anyway, here it goes: # emerge --info | grep ^\(CFLAGS\|USE\) CFLAGS=-O2 -march=native -pipe -fomit-frame-pointer USE=berkdb bindist bzip2 cli cracklib crypt cxx dri fortran gdbm gpm iconv modules ncurses nptl openmp pcre readline session ssl unicode x86 zlib ABI_X86=32 ALSA_CARDS=ali5451 als4000 atiixp atiixp-modem I was thinking of stuff like mmx mmxext sse sse2 sse3 ssse3 etc. This might accomplish the same work with fewer bytes of advanced machine language instructions, versus more bytes of standard instructions. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] bloated by gcc
On Mon, 29 September 2014, at 5:35 pm, Daniel Troeder dan...@admin-box.com wrote: … IMO you shouldn't compare 4.8.x with 4.9.x. Definitely this. OP should be doing everything he can to match the environment on both systems. This means matching versions of gcc, glibc and of all their libraries and other dependencies. And of the libraries and dependencies for the program he's attempting to compile. Note that gcc has a vanilla USE flag - I think it's disabled by default. Stroller.
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 7:03 PM, Stroller strol...@stellar.eclipse.co.uk wrote: On Mon, 29 September 2014, at 5:35 pm, Daniel Troeder dan...@admin-box.com wrote: … IMO you shouldn't compare 4.8.x with 4.9.x. Definitely this. OP should be doing everything he can to match the environment on both systems. This means matching versions of gcc, glibc and of all their libraries and other dependencies. And of the libraries and dependencies for the program he's attempting to compile. Since the problem is the same with dietlibc, glibc is not causing the discrepancy. And my program doesn't use any other library besides the C standard lib (glibc/dietlibc) and linux system calls. Emerging gcc 4.9.1 now... I'll try compiling my program against dietlibc, since replacing glibc seems scary. Note that gcc has a vanilla USE flag - I think it's disabled by default. Sorry, should have mentioned that. I had the default flags. I just tried vanilla in case some patch would be causing the problem. No difference. (Same applies to the nopie flag.) Thanks, Jorge
Re: [gentoo-user] bloated by gcc
On Mon, Sep 29, 2014 at 7:26 PM, Jorge Almeida jjalme...@gmail.com wrote: On Mon, Sep 29, 2014 at 7:03 PM, Stroller strol...@stellar.eclipse.co.uk wrote: OP should be doing everything he can to match the environment on both systems. Since the problem is the same with dietlibc, glibc is not causing the discrepancy. And my program doesn't use any other library besides the C standard lib (glibc/dietlibc) and linux system calls. Emerging gcc 4.9.1 now... I'll try compiling my program against dietlibc, since replacing glibc seems scary. gcc 4.9.1, dietlibc-0.33 (no dependencies whatsoever); Gentoo: 7011 (unstripped) 4116 (stripped with sstrip) LFS: 6207 (unstripped) 3340 (stripped with sstrip) Could binutils have something to do with this? Trying that... Jorge Almeida