Problems Compiling Geoip on linux-2.6.21-rc3

Problems Compiling Geoip on linux-2.6.21-rc3

[Nick Pasich]

Samuel,

Problem occurr when compiling geoip for Linux Kernel 2.6.21rc1 -> rc3 

Errors shown below.....

       Thanks,

         Nick Pasich


*****************************************************************************
*****************************************************************************

Kernel: arch/i386/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 256 modules
WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

*****************************************************************************
*****************************************************************************

[BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Samuel Jean]

On Wed, Mar 14, 2007, Nick Pasich <NewsLetters@NickAndBarb.net> said:

Hi Nick --

> Problem occurr when compiling geoip for Linux Kernel 2.6.21rc1 -> rc3

Yes. And I guess all patchlets from POM are broken too.  They all use
ipt_register/unregister functions which have been removed here :

[NETFILTER]: {ip,ip6}_tables: remove x_tables wrapper functions
author	Jan Engelhardt <jengelh@gmx.de>
	Wed, 7 Feb 2007 23:11:19 +0000 (15:11 -0800)
committer	David S. Miller <davem@sunset.davemloft.net>
	Thu, 8 Feb 2007 20:39:19 +0000 (12:39 -0800)
commit	6709dbbb1978abe039ea4b76c364bf003bf40de5
tree	fd0349415e398f9bc984461974a64c7024035356	tree | snapshot
parent	e1fd0586b04d624c597834320d9e57d6f2f4b878	commit | diff
[NETFILTER]: {ip,ip6}_tables: remove x_tables wrapper functions

Use the x_tables functions directly to make it better visible which
parts are shared between ip_tables and ip6_tables.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

Patrick --

How do we workaround the missing wrappers ? Another #if KERNEL_VERSION
declarations ?

> Kernel: arch/i386/boot/bzImage is ready  (#1)
>   Building modules, stage 2.
>   MODPOST 256 modules
> WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
> WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2

Best regards,
Samuel

Re: [BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Jan Engelhardt]

On Mar 15 2007 14:36, Samuel Jean wrote:
>
>How do we workaround the missing wrappers ? Another #if KERNEL_VERSION
>declarations ?
>
>> Kernel: arch/i386/boot/bzImage is ready  (#1)
>>   Building modules, stage 2.
>>   MODPOST 256 modules
>> WARNING: "ipt_unregister_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
>> WARNING: "ipt_register_match" [net/ipv4/netfilter/ipt_geoip.ko] undefined!
>> make[1]: *** [__modpost] Error 1
>> make: *** [modules] Error 2

#if DONT_HAVE_IPT /* nicely recent */
#    the wrappers as present before the commit
#endif
#if DONT_HAVE_XT /* really old kernel */
#    define xt_match ipt_match
#    define xt_register(x) do { (x)->family = AF_INET; ipt_register(x); }
#endif

Something like that. Oh yeah what a wonderful world
if pomngs were integrated! :>



Jan
-- 

Re: [BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Patrick McHardy]

Samuel Jean wrote:
> How do we workaround the missing wrappers ? Another #if KERNEL_VERSION
> declarations ?

I'm afraid so. The good news is that I've planned to encapsulate the
tons of (often unused) arguments to match/target functions in a
structure, so future changes at least won't change the function
signatures anymore.

Re: [BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Jan Engelhardt]

Hi,

Patrick McHardy wrote:
>Samuel Jean wrote:
>> How do we workaround the missing wrappers ? Another #if 
>> KERNEL_VERSION declarations ?
>
>I'm afraid so. The good news is that I've planned to encapsulate the
>tons of (often unused) arguments to match/target functions in a
>structure, so future changes at least won't change the function
>signatures anymore.

By the way, when doing that, could we change the xt_match->match, 
xt_match->checkentry and xt_target->checkentry functions to return bool, 
now that it's available?


Jan
-- 

Re: [BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Patrick McHardy]

Jan Engelhardt wrote:
>>I'm afraid so. The good news is that I've planned to encapsulate the
>>tons of (often unused) arguments to match/target functions in a
>>structure, so future changes at least won't change the function
>>signatures anymore.
> 
> 
> By the way, when doing that, could we change the xt_match->match, 
> xt_match->checkentry and xt_target->checkentry functions to return bool, 
> now that it's available?


I guess, although I don't think it will have any effect on the
generated code.

Re: [BROKEN] ipt_ wrappers for xt_ functions (WAS: Problems Compiling Geoip on linux-2.6.21-rc3)

[Jan Engelhardt]

On Mar 22 2007 14:49, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>>>I'm afraid so. The good news is that I've planned to encapsulate the
>>>tons of (often unused) arguments to match/target functions in a
>>>structure, so future changes at least won't change the function
>>>signatures anymore.
>> 
>> By the way, when doing that, could we change the xt_match->match, 
>> xt_match->checkentry and xt_target->checkentry functions to return bool, 
>> now that it's available?
>
>I guess, although I don't think it will have any effect on the
>generated code.

bool is usually an unsigned 8-bit entity (when it comes to code generation),
int is usually signed 32. (i386) But I guess that's nothing new.


Jan
--