>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
