If zlib is a module then it cannot be part of lib/lib.a, it has to be
separate, with changes to the top level Makefile to conditionally
include lib/zlib.o. I did that originally but the changes to
lib/Makefile and the top level Makefile were worse. Building zlib as a
module guarantees that you cannot use it in a boot loader, forcing you
to maintain multiple versions of zlib.c. If you are going to use one
version of zlib then you should try to handle bootloaders as well.
What is convoluted about my solution? The derivation of CONFIG_ZLIB in
the top level Makefile is ugly but that ugliness is a side effect of
CML1. CONFIG_ZLIB has to be derived somewhere, it is a smaller patch
to do it in Makefile than to patch 15 arch/*/config.in files. Apart
from that, the only other niggle is the dummy reference in init/main.c.
>I guess one other option would be to have an explicit user-set tristate
>like CONFIG_ZLIB, and if anything uses zlib, it could only be modules if
>CONFIG_ZLIB was a module, etc.
Don't ask the user, they will not understand the problem. CONFIG_ZLIB
is derived from other configs and possibly ARCH variables, users have
no direct control over CONFIG_ZLIB.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/