Thanks much! This is a great idea; I've adopted it. I changed the patch a bit so as to introduce the check only inside a header's #ifndef...#endif protection, when it has such protection.
Eddie On 10/26/10 1:28 AM, Harald Schioeberg wrote: > On Sun, 2010-10-24 at 09:45 -0700, Eddie Kohler wrote: >> Hi Harald, >> >> Great to hear about other people using patchless! >> >> Re: hweight32: That is definitely a missing CLICK_CXX_PROTECT. The way >> to find it is to use nm on the individual object files to find where >> it's used. Something like >> >> for i in *.o; do if nm $i | grep -l hweight32>/dev/null 2>&1; then echo >> $i; fi; done > > Hi Eddie, > this was my first idea, too, but it yielded every single .o file.... > > I traced down the bug by prepanding that to every linux header > (thanks for fixincludes.pl ;-) > > #ifdef __cplusplus > # ifndef CLICK_CXX_PROTECTED > # error "This file can only be included in CLICK_CXX_PROTECT stancas" > # endif > #endif > > compiles and loads for me now, patches attached > > (0002 is ommited for mailinglist friendliness, its just the huge diff > autoconf will generate on the configure...) > >> More soon. >> >> Eddie >> >> >> On 10/24/10 8:21 AM, Harald Schioeberg wrote: >>> Hi, >>> >>> i'm currently trying to catch up with the patchless stuff, see below for >>> my current status. >>> >>> I tried against the weird ubuntu-maverick kernel, but then >>> I stepped back a bit to vanilla 2.6.27.54 on i386 for the moment. >>> This gives me a click build, but with: >>> >>> WARNING: >>> "_Z9hweight32j" [/data/harald/patchless/click/linuxmodule/click.ko] >>> undefined! >>> and of course a failure to load the "click" module, the proclikefs >>> loads. >>> >>> Apparently hweigth32 is not CXX_PROTECTed, any ideas why this might >>> happen? >>> Its in click-linuxmodule/include0/asm-generic/bitops/hweight.h >>> which should only be included via<linux/bitops.h>, but I have not found >>> any unprotected "#include<linux/bitops.h>" or related stuff anywhere. >>> >>> Here I am starting from eddie/96471bf1 + from Joonwoo. >>> >>> [joonwoo 01/12] >>> This fixes a configury issue, but the real compile will use [joonwoo >>> 9/12], which is in mainline by now as 340c5ebe >>> IMHO this needs some means to emulate >>> LINUX_VERSION_CODE< KERNEL_VERSION(2, 6, 33) >>> in the configure to make it "nice" >>> >>> [joonwoo 02/12] >>> I didn't need that one until now... >>> >>> [joonwoo 03/12] >>> Same here >>> >>> [joonwoo 04/12] >>> Used joonwoo's patch, discussion is ongoing between eddie and joonwoo >>> >>> [joonwoo 05/12] [joonwoo 06/12] are in mainline >>> >>> [joonwoo 07/12] >>> used the patch from joowoon, >>> eddie already confirmed the patch, but it's not in mainline yet >>> >>> [joonwoo 08/12] >>> eddie checked in A Different Version >>> >>> [joonwoo 09/12] >>> it's upstream, related to 01/12 >>> >>> [joonwoo 10/12 and 11/12] >>> they are upstream >>> >>> [joonwoo 12/12] >>> A Different Version is upstream as a5f200d >>> >>> _______________________________________________ >>> click mailing list >>> click@amsterdam.lcs.mit.edu >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list click@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
