ANSI C++ : Why such a vast difference in executable size on differnent platforms?
Author
Hi All,
I've written a program in C++ and compiled it on three platforms. There is a vast difference in program size, particularly on Mac OSX 10.2.8.
Linux Gentoo (the primary development platform) g++ v3+ with -ansi -O3 -s size: 240k.
WinXP MinGW g++ v3+ with -ansi -O3 -s size: 520k.
MacOSX 10.2.8 g++ v3+ with -ansi -O3 (won't accept -s or -x) size: 3.2mb !!
I don't understand this unless it has something to do with dynamic c++ std libraries on my Mac. Why has this happened?
--random
I do know that with XP + MinGW part of the issue is the static linking of the standard library - don't know about Mx OSX. Does mac have strip? Also, although I'm not an expert on the compiler options, -g0 may help... IIRC my Eclipse IDE adds this in it's "release" mode with the managed makefile projects...
Most of this overhead is once-per executable rather than a percentage increase, so I wouldn't worry too terribly much about it...
Most of this overhead is once-per executable rather than a percentage increase, so I wouldn't worry too terribly much about it...
Author
--Mauling
Thanks for your info. I thought that the -s or -x linker option was for strip. The Mac won't accept this setting, although Linux and WinXP/MinGW will.
Time-wise, with regard to random number speed tests, the Gentoo Linux OS is about 10% faster than the WinXP/MinGW executable ( I run these OS's as dual boot systems ). This is really negligible, and could be explained by the way I'm carryiing out the tests. The MacOSX is on a laptop and really can't be compared time-wise, as it is a much slower machine.
I'll have a look at the -g0 compiler option. It just seems strange that the executable can be larger by more than a factor of 10. I know that OSX 10.2 is really built around Objective C and may be lacking in C++ dynamic libraries.
I can't comment on the new Tiger OS with Mac with XCode, maybe it has a more complete set of C++ libraries.
--random
Thanks for your info. I thought that the -s or -x linker option was for strip. The Mac won't accept this setting, although Linux and WinXP/MinGW will.
Time-wise, with regard to random number speed tests, the Gentoo Linux OS is about 10% faster than the WinXP/MinGW executable ( I run these OS's as dual boot systems ). This is really negligible, and could be explained by the way I'm carryiing out the tests. The MacOSX is on a laptop and really can't be compared time-wise, as it is a much slower machine.
I'll have a look at the -g0 compiler option. It just seems strange that the executable can be larger by more than a factor of 10. I know that OSX 10.2 is really built around Objective C and may be lacking in C++ dynamic libraries.
I can't comment on the new Tiger OS with Mac with XCode, maybe it has a more complete set of C++ libraries.
--random
Author
When I say that Mac won't accept -s or -x, I mean that these are valid g++ v3+ compiler options, but when used on the Mac I get tons of symbol-related error statements, and the program won't compile and link. When these flags are removed, the program compiles and links without any errors on the Mac.
--random
--random
From the GCC(1) manpage
Also, statically linking should increase size, dynamically linking should decrease size.
EDIT: Yes, OS X has the strip command.
Quote:
-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza-
tions designed to reduce code size.
Also, statically linking should increase size, dynamically linking should decrease size.
EDIT: Yes, OS X has the strip command.
Author
Here are my flags copied verbatim from the Makefiles:
For Linux makefile:
LNXCCFLAGS = -g -c -O3 -fforce-addr -ffast-math -Wall -ansi -pipe
LNXLDFLAGS = -s
For Mac OSX makefile:
OSXCCFLAGS = -g -c -O3 -fforce-addr -ffast-math -Wall -Wno-long-double -ansi -pipe
OSXLDFLAGS = # Do not use -s or -x here.
I tried -s and -x on the Mac, with fatal error. I'll try -0s on the Mac (thanks Robo) and see what happens.
--random
For Linux makefile:
LNXCCFLAGS = -g -c -O3 -fforce-addr -ffast-math -Wall -ansi -pipe
LNXLDFLAGS = -s
For Mac OSX makefile:
OSXCCFLAGS = -g -c -O3 -fforce-addr -ffast-math -Wall -Wno-long-double -ansi -pipe
OSXLDFLAGS = # Do not use -s or -x here.
I tried -s and -x on the Mac, with fatal error. I'll try -0s on the Mac (thanks Robo) and see what happens.
--random
Author
Hi All
Here's some interesting results; using the -Os flag on the Mac reduced the program size from:
3.2 mb to 1.7 mb.
I also tested the speed of random number generation and the -Os flag has also improved the speed over the -O3 version by about 5 to 10%!
So the -Os flag cut the size by about a factor of 2 and has improved performance by about 5 to 10%.
--random
Here's some interesting results; using the -Os flag on the Mac reduced the program size from:
3.2 mb to 1.7 mb.
I also tested the speed of random number generation and the -Os flag has also improved the speed over the -O3 version by about 5 to 10%!
So the -Os flag cut the size by about a factor of 2 and has improved performance by about 5 to 10%.
--random
Author
Again on the Mac, when using the -s option, I get the following linker message:
"ld: can't use -s with input files containing indirect symbols (output file must contain at least global symbols, for maximum stripping use -x)"
This message is not there when I make the file on Linux and WinXP/MinGW. Any thoughts?
--random
"ld: can't use -s with input files containing indirect symbols (output file must contain at least global symbols, for maximum stripping use -x)"
This message is not there when I make the file on Linux and WinXP/MinGW. Any thoughts?
--random
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
