Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: niffiwan on November 05, 2011, 07:17:36 am
-
chief1983's comment in this sticky (http://www.hard-light.net/forums/index.php?topic=56470.0) about the size of the OSX/Linux binaries got me thinking about reducing the size of said binaries (well, for Linux at least since I don't have a Mac/Xcode - but I guess being gcc based this may apply there too?).
I have noticed that the release builds have all the debug symbols compiled in (-g). Given that we have debug builds to, well, debug issues, this seems redundant. We could compile without -g, which will substantially reduce the size of the binary (i.e. <50%). I presume that something similar is what the Windows binaries currently do?
I guess there's always a chance that a problem will occur in release build, but not in debug. However in that case the person investigating the issue could do a custom compile of "release" with -g. For the rest of the time though, it just uses extra download bandwidth (assuming that the number of downloads of the Linux binaries are significant... they quite easily may not be)
Comments?
-
chief1983's comment in this sticky (http://www.hard-light.net/forums/index.php?topic=56470.0) about the size of the OSX/Linux binaries got me thinking about reducing the size of said binaries (well, for Linux at least since I don't have a Mac/Xcode - but I guess being gcc based this may apply there too?).
I have noticed that the release builds have all the debug symbols compiled in (-g). Given that we have debug builds to, well, debug issues, this seems redundant. We could compile without -g, which will substantially reduce the size of the binary (i.e. <50%). I presume that something similar is what the Windows binaries currently do?
I guess there's always a chance that a problem will occur in release build, but not in debug. However in that case the person investigating the issue could do a custom compile of "release" with -g. For the rest of the time though, it just uses extra download bandwidth (assuming that the number of downloads of the Linux binaries are significant... they quite easily may not be)
Comments?
i believe that most linuxers actually self-compile.
AFAIK, the nightly linux binaries are Ubuntu based, and said binaries arent known for running on non-ubuntu/debian distros.
-
They may self-compile, but they're still using our autoconf script, and we could probably set it up to pass the strip command to the release binaries so that anyone who builds it gets a smaller executable.
-
I've done some testing with "strip".
.all = strip -s
.only-debug = strip -g
-rwxr-xr-x 1 me me 24384059 2011-11-03 07:20 fs2_open_3.6.14_DEBUG_RC1
-rwxr-xr-x 1 me me 25949769 2011-11-03 07:45 fs2_open_3.6.14_RC1
-rwxr-xr-x 1 me me 4115324 2011-11-06 08:23 fs2_open_3.6.14_RC1.all
-rwxr-xr-x 1 me me 4828493 2011-11-06 08:23 fs2_open_3.6.14_RC1.only-debug
And here's the (almost) same binary compiled without -g (it's 64bit vs 32bit above)
-rwxr-xr-x 1 me me 4473768 2011-11-06 08:26 fs2_open_3.6.14
The size differences are so small it wouldn't matter which way we go with this.
In any case, removing -g from compile flags is just as easy as adding -s (to strip on compile). If we want to strip after compile it'll need a little more work.
-
They may self-compile, but they're still using our autoconf script, and we could probably set it up to pass the strip command to the release binaries so that anyone who builds it gets a smaller executable.
point very well made. silly me.
-
Niffiwan, you're right, I was kind of missing the point of what you were talking about earlier. Removing -g on release builds sounds like the way to go.
-
Thanks - committed to trunk in r7957 (http://svn.icculus.org/fs2open?view=rev&revision=7957)