Messages in this thread | | | From | Keith Owens <> | Subject | Re: Moving zlib so that others may use it | Date | Thu, 10 Jan 2002 16:40:00 +1100 |
| |
On Wed, 09 Jan 2002 23:13:28 -0600, Corey Minyard <minyard@acm.org> wrote: >Hmm. It worked fine for me. I made it a module, and it put it into >kernel/lib in >/lib/modules/2.4.17 and it did not put it in lib/lib.a I make it a >non-module, and >it gets included in lib/lib.a. My diff was the same as yours for the >Makefile.
Worked for me this time as well. I had a typo the first time then did an ugly fix to a non-existent problem :(
>I don't know about the bootloaders. I'm not sure you can make the >requirement >to have them compiled the same as the kernel, since they may have different >compilation requirements in the boot loader.
Probably true, but I don't want to rule it out completely. In any case it is easily catered for in lib/Makefile.
obj-$(CONFIG_JFFS2_FS) += zlib.o obj-$(CONFIG_PPP_DEFLATE) += zlib.o # Uncomment these if ppc bootloader can use the common zlib # ifeq ($(ARCH),ppc) # obj-y += zlib.o # endif
>The problem is that if you come along later and compile a new module that >needs it, it won't work. That's a fairly common thing I do, I expect >other kernel >developers do the same. And the dummy ref thing is a little ugly.
Any new module that requires zlib requires a change to the zlib selection. Whether you do it in the top level Makefile, in lib/Config.in or lib/Makefile is irrelevant, zlib has to be selected somewhere and the criteria must be updated for new modules.
Since lib/zlib.c works for both built in and modules, there is no need to change the top level Makefile. AFAICT the above lines in lib/Makefile are the minimal change.
- 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/
| |