Missing ns_initparse

[Daniel Mack]

On Sat, Jul 9, 2011 at 2:11 PM, Rich Felker <dalias at aerifal.cx> wrote:
> On Sat, Jul 09, 2011 at 11:43:36AM +0200, Daniel Mack wrote:
>> On Sat, Jul 9, 2011 at 9:06 AM, Bernhard Reutner-Fischer
>> <rep.dot.nop at gmail.com> wrote:
>> > All functions should remain in Linbc, the libresolv stub should be kept
>> > as-is (as a dummy lib) . How big is it, size (1) wise resp. Bloat-o-meter
>> > wise?
>>
>> The .text section grew by ~5k from 262947 to 268335 bytes in libc, and
>> from 42 bytes to 3985 bytes in libresolv.
>>
>> And because it adds some code, I'm curious why you would like to have
>> everything in libc instead of leaving it to the user whether support
>> for these symbols is needed at all. For a system with no network
>> support at all, for example, users could decide to save some bytes by
>> not adding it. And all packages I've seen so far include -lresolv in
>> case they need the resolver functions.
>
> Note that if you're using shared libraries, the very fact that you're
> loading an additional shared library wastes *at least* 4-5k of
> non-sharable dirty memory *per process*, not just space in the
> filesystem. And for static libraries, only the modules that are
> referenced will get linked anyway. Splitting up libc into multiple .a
> or .so files is simply a huge inefficiency that should be abolished.

Ok, that's a valid point. So what you say is that these modules should
only be part of the library if the user decided to add them, but they
will end up in the libc?

That would mean that CONFIG_LIBRESOLV_STUB has influence to whether
the resolver symbols end up in the libc? Or would you build and link
them unconditionally?


Thanks for the explanation :)

Daniel