Err, binary size on linux!?

#1 Well it's that big binary because of all the debugging symbols gcc puts in to help in debugging. I believe this is the normal size but i don't have a debug build readdy atm to tell you exactly. Don't worry your regular binary comes out at a normal size. I think one time tho i had to strip the debugging symbols out of my release binary to make it a good size but It's been a while.

--KallDrexx

#2 Hey Stefan,

stop complaining.. gcc3 on Solaris/Sparc gives me a 71Mb debug binary... :)

nobody@myhost:[/var/tmp/torque/engine/out.GCC3.DEBUG][516]$ ls -la torqueDemo_DEBUG.bin
-rwxr-xr-x 1 root other 74931908 Jul 16 12:43 torqueDemo_DEBUG.bin

nobody@myhost:[/var/tmp/torque/engine/out.GCC3.DEBUG][517]$ gls -lh torqueDemo_DEBUG.bin
-rwxr-xr-x 1 root other 71M Jul 16 12:43 torqueDemo_DEBUG.bin

nobody@myhost:[/var/tmp/torque/engine/out.GCC3.DEBUG][518]$ gfile ./torqueDemo_DEBUG.bin
./torqueDemo_DEBUG.bin: ELF 32-bit (SYSV) MSB executable, SPARC, version 1, dynamically linked (uses shared libs), not stripped

nobody@myhost:[/var/tmp/torque/engine/out.GCC3.DEBUG][519]$ ldd ./torqueDemo_DEBUG.bin
libGLU.so.1 => /usr/lib/libGLU.so.1
libX11.so.4 => /usr/lib/libX11.so.4
libXext.so.0 => /usr/lib/libXext.so.0
libpthread.so.1 => /usr/lib/libpthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
librt.so.1 => /usr/lib/librt.so.1
libkstat.so.1 => /usr/lib/libkstat.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libGL.so.1 => /usr/lib/libGL.so.1
libintl.so.1 => /usr/lib/libintl.so.1
libdga.so.1 => /usr/openwin/lib/libdga.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libaio.so.1 => /usr/lib/libaio.so.1
libXmu.so.4 => /usr/lib/libXmu.so.4
libXt.so.4 => /usr/lib/libXt.so.4
libSM.so.6 => /usr/lib/libSM.so.6
libICE.so.6 => /usr/lib/libICE.so.6
libthread.so.1 => /usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1


Vincent

#3 Yeah, and around 50+ megs with PB/Gcc on MacOS X for the Debug, and 7 and some megs for Release :)

#4 Jeez! :P
/ME shuts up... ;)
btw, it's only 4,7 MB for our project on linux in Release build, so I guess I can live with that :)

#5 On windows, the Debug Build is 5.5MB or so... the release is about 2 somethin

#6 @Bryan: so? I think no one was trying to start a flame war here. They use different ways of doing debug, and yes in Linux debug binaries end up being lots bigger.

#7 Yep, Bryan, and that's because the debug symbols are kept in a seperate file and not compiled in with the executable.

#8 The main problem with having such a massive debug binary, other than you can't distribute it easily, is that it takes a long time to link. You can workaround this by removing the -g flag from the conf.UNIX.mk file and doing a clean rebuild. The binary will be much smaller (and the link faster), but won't be very useful for debugging (stack traces will still be somewhat useful though).

You could also do the linking on a RAM disk...but I haven't experimented with this method :)

#9 @Exodus: What is your problem? Bryan was simply stating what the sizes were for Win32 just like everybody else was stating what the sizes were for their target platform, geez. I see nothing flaming about his statement what so ever.

#10 @Nathan: Thing is that no one was comparing it to windows in the original question... all flame wars start that way... someone speaks about something and then someone else pokes in a comment about the "other side". So then the orignal side jumps in and so on. The question was about Linux binaries... not about Linux vs Windows or binary sizes on different OS's.
That's it.

#11 Linux binaries get big when you do a build that has debugging information in it, don't forget that it's not just the binary that gets it, but the libs get it too - and as far as I recall, Torque itself is linked statically into the binary which tends to make it grow a bit chunky - doubly so with the debugging symbols.

My Torque demo debug build is a rough 37 megs in size - haven't yet checked a release build since .. well.. I only got Torque yesterday and I'm still trying to figure out what the heck I'm doing ;)

#12 @Bernhard: haha, you'll figure what you are doing real soon, you seem to know your linux compiling stuff :)
Good Luck with it, and yes, torque does compile some stuff statically, among other things lGLU... we've been talking with John Quigley to remove this static linking since we found problems when adding more GLU functions where Torque would just crash when accessing those functions.