Re: lynx-dev bloating binaries (was clue)

[Webmaster Jim]

On Fri, Feb 26, 1999 at 11:42:37AM +0900, Henry Nelson wrote:
> > Do you have a list of "features" you want to see as compile time options
> To mention this is unfair since Jim is already working on it, but as
> an example of the humongous amount of debugging code, there needs to
> be a way to turn off CTRACE and TRACE. The saving in binary size is
> significant. In _release_ (production-level) code sets, the toggle to
> turn trace on/off should not be compiled in as the default.

"Working on it" is too kind a phrase; I forced a compile to not include
traces and it reduced the binary size about 10%, IIRC. I haven't gone
back to the configure drawing board yet to iron out the logic (2 weeks
of thought, 2 lines of code :-).

The real code bloat is features which users request: look at the -help
output for instance:

-rwxr-xr-x  1 jim   wheel  1120499 Jan 30 17:20 lynx
-r-xr-xr-x  1 root  wheel   565248 Jan 20  1997 lynx2-6FM

05:39:45/jim> ./lynx2-6FM -help | wc -l
      81 
05:39:52/jim> ./lynx -help | wc -l
     117 

That's almost 50% more command line options, not to mention configurable
behaviour on startup or on-the-fly,


The 2-6FM file was stripped (but that doesn't shrink current much):

05:40:07/jim> file lynx2-6FM 
lynx2-6FM: NetBSD/i386 demand paged dynamically linked executable
05:44:09/jim> file lynx
lynx: NetBSD/i386 demand paged dynamically linked executable not stripped
05:44:16/jim> strip lynx
05:44:26/jim> ls -l lynx
-rwxr-xr-x  1 jim  wheel  1040384 Feb 26 05:44 lynx

The last time I looked, there were places where static arrays are
allocated that could be made dynamic, shrinking the binary a bit, as
well as avoiding buffer overruns if done correctly.

++++++++++++++++++++++++++++
Marvin the Paranoid Android.