Modular puppyvisor started giving linking errors
	  MODPOST 1 modules

	ERROR: "kasprintf" [drivers/lguest/lg.ko] undefined!
Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>

---
 lib/Makefile |    4 ++--

 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/lib/Makefile

+++ b/lib/Makefile

@@ -2,7 +2,7 @@

 # Makefile for some libs needed in the kernel.

 #
-lib-y := ctype.o string.o vsprintf.o kasprintf.o cmdline.o \

+lib-y := ctype.o string.o vsprintf.o cmdline.o \

 	 rbtree.o radix-tree.o dump_stack.o \

 	 idr.o int_sqrt.o bitmap.o extable.o prio_tree.o \

 	 sha1.o irq_regs.o reciprocal_div.o argv_split.o

@@ -13,7 +13,7 @@ lib-$(CONFIG_SMP) += cpumask.o

 lib-y	+= kobject.o kref.o kobject_uevent.o klist.o
 obj-y += div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \

-	 bust_spinlocks.o hexdump.o

+	 bust_spinlocks.o hexdump.o kasprintf.o
 ifeq ($(CONFIG_DEBUG_KOBJECT),y)

 CFLAGS_kobject.o += -DDEBUG
-

Please kill lib-y while you're at it.  It's useless and a constant

source of pain like this.
-

Kernel-bloat is another "constant source of pain".

But the troubles are that increased blot does not result in compiler erros.
And your proposal to kil lib-y is a counter-act here.
	Sam

-

Killing lib-y doesn't create kernel bloat if done right.  Just introduce

proper Kconfig dependencies for the truely optional parts.  But if you

look at the list of objects in lib-y you'll see that they fall in basically

three categories:
 (1) always used by core code - should be obj-y

 (2) generic implementation for arch-specific functionality, should be

     guarded by Kconfig for clarity reasons anyway

 (3) library code often but not always used by code that's not always

     built in.  Here we run into the move to obj-y to avoid compiler

     warning when used as module issue all the time.  Adding a CONFIG

     for the bigger onces actually avoids bloat over obj-y here, and

     when it's small enough obj-y is a lot safer in the presence of

     modular users
Really, trying to use the old static library use on demand concept simply

doesn't fit the way the kernel is built with it's modules and dependencies.

-

I objected to just killing lib-y (the way I read your original proposal).

If we introduce proper kconfig dependencies as in (3) then I am all for it.
	Sam

-

yup, it duplicates what the config system does and is a common source of

problems.

-