![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-03-22 12:15 [W:0.158 / U:0.010 seconds] ©2003-2008 Jasper Spaans | ||||||||||