Re: Trivial program size inflation

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Oh, I didn't mean the program needing to call dlopen() directly.
>> libc itself may load shared objects to support things like i18n and
>> NSS on an as-needed basis.

But that support shouldn't be brought in if the program doesn't use
i18n, NSS, or whatever.

As in, sure, let's say i18n_something.o refers to dlopen.  But if
i18n_something.o itself is not brought in, its reference to dlopen
won't be brought in either.

> And only old guys like me still care about the size of the
> executable...

Yeah, the hip new kids never use anything with fewer than 4
multi-gigahertz cores and RAM load most easily measured in tens of
gigs (cf NetBSD's "industrially relevant" wording).  If that's a
low-end machine, yes, half a meg of overhead _is_ ignorable.

...and, these days, you have to look for specialty channels
(embedded-hardware vendors and the like, or retrocomputing geeks like
me) to find anything much smaller than that.

Even the "tiny" machines these days are ridiculously overpowered.  I
have a machine on my desk, for example, which runs off one USB cable,
meaning it can't be drawing more than, IIRC, five watts.  The box is
maybe 2"x2.5"x4".

It's a quad-core ARMv7 with a bit under a gig of RAM - I suspect 1G but
with various things stealing pieces of it.  (I haven't found a way to
get it to cough up the CPU clock rate; it's stuck running a Linux
variant, and I am not that familiar with Linux.  It's a Pi of some
stripe, I believe.)  And work, which is why I have it at all, is
talking about it being underpowered enough to replace it with something
even more ridiculous.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B