From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Lougher Subject: Re: [PATCH -next] libs: force lzma_wrapper to be retained Date: Sun, 03 Jan 2010 00:55:55 +0000 Message-ID: <4B3FEB1B.7040106@lougher.demon.co.uk> References: <20100101120737.94d4acc4.sfr@canb.auug.org.au> <20100101183344.398f2538.randy.dunlap@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100101183344.398f2538.randy.dunlap@oracle.com> Sender: linux-kernel-owner@vger.kernel.org To: Randy Dunlap Cc: Stephen Rothwell , linux-next@vger.kernel.org, LKML , Michal Marek , akpm List-Id: linux-next.vger.kernel.org Randy Dunlap wrote: > From: Randy Dunlap > > When CONFIG_SQUASHFS=m and CONFIG_DECOMPRESS_LZMA=m, decompress_lzma > is built but then discarded from the library because no built-in code > uses it, so change it from a lib- to an obj- to force it to be kept > in the library. > > ERROR: "unlzma" [fs/squashfs/squashfs.ko] undefined! > Thanks for fixing this, I should have spotted it in my various config tests but didn't. I could add this to my squashfs-next patches to stop the linux-next tree breakage, however, should it go into Michal's kbuild -next tree instead? This patch raises a small additional issue, why is DECOMPRESS_LZMA (and DECOMPRESS_GZIP/DECOMPRESS_BZIP2) and defined as tristate? None of the above compressors can be built as modules. Regards Phillip