-------- Original-Nachricht -------- > Datum: Sat, 9 Jul 2011 16:00:15 +0200 > Von: Daniel Mack <[email protected]> > An: Rich Felker <[email protected]> > CC: [email protected] > Betreff: Re: Missing ns_initparse
> On Sat, Jul 9, 2011 at 2:11 PM, Rich Felker <[email protected]> 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 > >> <[email protected]> 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? you might add a new config option enabling these functions > 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? libresolv.* is built only if the above option is enabled, but does not provide any usable functions, allowing apps that hardcode -lresolv to find something Peter > > > Thanks for the explanation :) > > Daniel > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
