[gentoo-user] bloated by gcc

[gentoo-user] bloated by gcc

[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

[gentoo-user] Re: bloated by gcc

[walt]

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.

Re: [gentoo-user] Re: bloated by gcc

[Jorge Almeida]

On Sun, Sep 28, 2014 at 10:56 PM, walt <w41ter@gmail.com> wrote:
> On 09/28/2014 01:44 AM, Jorge Almeida wrote:
>> I'm having a somewhat disgusting issue on my Gentoo: binaries are
>> unaccountably large.
>>

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

Nope. Actually, I compiled with --march=native, with no difference
(probably because my code is not fancy enough to make use of whatever
stuff that pulls), but then tried i686 just to enable comparing with
non-Gentoo systems.
The purpose is to have small static binaries compiled against dietlibc
to be used in the same computer (compile once and forget about future
software incompatibilities!). I compiled against glibc to make sure
the problem is not with dietlibc.
>
> 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.
>
I found those flags in the net (probably StackOverflow), looking for
ways to optimize size. Maybe what you read was not meant to static
compiling?
Anyway, I used these flags in 4 systems (including LFS in the same
computer as Gentoo) and only the Gentoo system has this behaviour...

Thanks,

Jorge
>

Re: [gentoo-user] bloated by gcc

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] bloated by gcc

[Jorge Almeida]

On Mon, Sep 29, 2014 at 12:18 PM, Walter Dnes <waltdnes@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

[Marc Stürmer]

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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 3:50 PM, Marc Stürmer <mail@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

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] bloated by gcc

[Kerin Millar]

On 29/09/2014 16:10, Jorge Almeida wrote:
> On Mon, Sep 29, 2014 at 3:50 PM, Marc Stürmer <mail@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 4:15 PM, Walter Dnes <waltdnes@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 4:25 PM, Kerin Millar <kerframil@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

[Poison BL.]

On Mon, Sep 29, 2014 at 12:02 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 4:25 PM, Kerin Millar <kerframil@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

[Daniel Troeder]

[-- Attachment #1: Type: text/plain, Size: 5124 bytes --]

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=get&search=0x837FB8B5BB9D4887
* $ gpg --recv-keys --keyserver keyserver.ubuntu.com 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] bloated by gcc

[Rich Freeman]

On Mon, Sep 29, 2014 at 10:50 AM, Marc Stürmer <mail@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 5:35 PM, Daniel Troeder <daniel@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 5:20 PM, Poison BL. <poisonbl@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 12:02 PM, Jorge Almeida <jjalmeida@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

[Walter Dnes]

On Mon, Sep 29, 2014 at 04:32:40PM +0100, Jorge Almeida wrote
> On Mon, Sep 29, 2014 at 4:15 PM, Walter Dnes <waltdnes@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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] bloated by gcc

[Stroller]

On Mon, 29 September 2014, at 5:35 pm, Daniel Troeder <daniel@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 7:03 PM, Stroller
<stroller@stellar.eclipse.co.uk> wrote:
>
> On Mon, 29 September 2014, at 5:35 pm, Daniel Troeder <daniel@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

[Jorge Almeida]

On Mon, Sep 29, 2014 at 7:26 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:
> On Mon, Sep 29, 2014 at 7:03 PM, Stroller
> <stroller@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

Re: [gentoo-user] Re: bloated by gcc

[J. Roeleveld]

On Monday, September 29, 2014 12:37:37 AM Jorge Almeida wrote:
> On Sun, Sep 28, 2014 at 10:56 PM, walt <w41ter@gmail.com> wrote:
> > On 09/28/2014 01:44 AM, Jorge Almeida wrote:
> >> I'm having a somewhat disgusting issue on my Gentoo: binaries are
> >> unaccountably large.
> > 
> > Are you cross-compiling for different hardware?  I'm just curious what
> > results you get with --march=native.
> 
> Nope. Actually, I compiled with --march=native, with no difference
> (probably because my code is not fancy enough to make use of whatever
> stuff that pulls), but then tried i686 just to enable comparing with
> non-Gentoo systems.
> The purpose is to have small static binaries compiled against dietlibc
> to be used in the same computer (compile once and forget about future
> software incompatibilities!). I compiled against glibc to make sure
> the problem is not with dietlibc.

Did you compile the used libraries using the exact same options on both 
systems as well?
When compiling a static binary, the libraries are included into the resulting 
binary.
If the libraries on Gentoo are bigger, the resulting static binary will also 
be bigger.

--
Joost

Re: [gentoo-user] Re: bloated by gcc

[Jorge Almeida]

On Tue, Sep 30, 2014 at 8:04 AM, J. Roeleveld <joost@antarean.org> wrote:
>


>
> Did you compile the used libraries using the exact same options on both
> systems as well?
> When compiling a static binary, the libraries are included into the resulting
> binary.
> If the libraries on Gentoo are bigger, the resulting static binary will also
> be bigger.
>
Yes, the library (dietlibc) is compiled typing just "make". The
Makefile is not modified. I rebuild it with gcc 4.9.1. There are no
other libraries involved.

When using glibc I didn't made a static binary, and even so it was
larger on Gentoo.

Thanks

Jorge