the cloop-2.00.ebuild tells you to enable zlib compression/deflation but fails to warn you to enable at least one option in order to link zlib into the kernel. As a result, the ebuild will compile/install a bad cloop.o and not tell you about it. Reproducible: Always Steps to Reproduce: 1. enable the two zlib options (inflate/deflate) in your 2.4.x kernel config, but enable no further options that make use of zlib. 2. emerge cloop (2.0) 3. the ebuild succeeds, but do a depmod -a and see the unresolved symbols Actual Results: the ebuild succeeds, but the cloop.o module is borked due to unresolved symbols. Expected Results: succes, or failure ala cloop-0.68 ebuild, anthing but the current result. The ebuild should have either A) done an nm | grep -i zlib on /usr/src/linux/System.map or B) checked the CONFIG_ options to ensure that zlib support was in fact present in the configured kernel. the .68 ebuild warns you to this effect by checking the config options
oops dunno what the hell that nm | grep -i was all about - should have been grep -i zlib in /usr/src/linux/System.map, or similar.
Which options do make use of zlib?
See the 0.68 ebuild, it performs the check i refer to here, and on failure reports what you *could* have enabled in order for the ebuild to succeed. Examples include things like ppp with compression (maybe just ppp?) deflate crypto algorithms, iso9660 with the transparent com/decomp option, etc.
the 2.00 ebuild has this: . ${KERNEL_DIR}/.config || die "kernel has not been configured yet" [ "$CONFIG_ZLIB_INFLATE" != "y" ] && badconfig [ "$CONFIG_ZLIB_DEFLATE" != "y" ] && badconfig that falls under your second solution ... if i missed something, please re-open with more info about what needs to be done to resolve this
I'm not touching the status - it's been months since this bug has lain dormant and I haven't checked cloop since then. Please decide for yourself whether a new cloop or new kernel somehow solves this. That said: that wouldn't help - that checks for zlib support, as you know. The problem is, even with those options checked off, and the zlib objects built, nothing will link against them unless it has to. In other words, if the user doesn't enable any of the options that *use* zlib, "the iso9660 transparent compression support" for example, then it doesn't get linked, and a later module trying to use these functions doesn't work because they never got linked into the kernel. So, kernel prerequisites are BOTH OF THE FOLLOWING a) what you have below b) one of the many options I reference in "the 0.68 ebuild" (below) being enabled.
hmm, i wonder if that is a gcc bug then ... and/or the kernel peeps have added gcc attribute calls to work around this ... if you enable features, they shouldnt be stripped from the kernel simply because they never get used by things you've added ... ive never used cloop before so i cant really test it myself :/
