lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev bloating binaries (was clue)


From: Henry Nelson
Subject: Re: lynx-dev bloating binaries (was clue)
Date: Mon, 1 Mar 1999 10:23:40 +0900 (JST)

> "Working on it" is too kind a phrase; I forced a compile to not

Hardly. You have done and continue to do a LOT to the development of
Lynx and the working environment for other developers.

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

Command line options are in great demand by the Lynx user community.
In general I think they are a "good" thing for Lynx in that they take
some of the decision making out of the hands of the sysadmins who can be
rather inflexible at times. They help users make better use of Lynx.

I would only like to see at least as much time being spent on cutting
the code entirely out if the person compiling Lynx wants it that way.
There is still a significant percentage of people on this list who
compile a binary for their own private use. They know what they want;
they also know what they don't want. The prime example I would use is
dired. All I need do is add "--disable-dired" to my configure options
and I know my binary size will drop considerably. When I am in a tight
situation, or I know the binary is only going to be used by novices,
that is an "option" I want; and that option loses all of its value if
it's left in for a command line option or cfg/rc option.

> The last time I looked, there were places where static arrays are
> allocated that could be made dynamic, shrinking the binary a bit, as

I would hate to start up another thread here, but I don't think dynamic
linking always means better. In some situations, I believe static
linking can be more economical. The binary itself may look smaller, but
you could end up actually using more memory to get it loaded. And if the
libraries are not really "shared", but actually only used for linking to
the one program Lynx, then more disc space is being eaten up than need
be. Using shared libraries tends to tether a binary to one machine that
has all the shared libraries in all the same places. If dynamic linking
is the default by the OS, e.g., FreeBSD, then that's probably the way to
go. But if it isn't, it might be wise to stick to the static default.

I'll just say one more thing because my thread here seems to have caused
some developer "bashing". That is/was NOT my intent. I think the developers
past and present are doing a WONDERFUL job. I think they have all been
remarkably concerned about portability issues and often go to great lengths
to watch out for the underdog. OTOH, a LOT of what I say is based on
misconceptions and ignorance. If anyone, I'm the one to be bashed.

__Henry

reply via email to

[Prev in Thread] Current Thread [Next in Thread]