Bug 21604 - Problem with ip_masq.c when compiling kernel
Summary: Problem with ip_masq.c when compiling kernel
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
: 29384 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-01 22:10 UTC by umkay
Modified: 2007-04-18 16:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-02-15 17:33:37 UTC
Embargoed:


Attachments (Terms of Use)

Description umkay 2000-12-01 22:10:11 UTC
I've had all sorts of problems compiling kernels with Red Hat 7.0.   First
I had bug # 18001.  When I fixed that bug, I ran into bug # 18954.  Now
I've fixed that, and have hit a bug that I could not find previously
reported.

  In short after running make mrproper, re-configuring the kernel with make
menuconfig, editing the Makefile to change the CC definition, running make
dep, and finally running make bzImage, I get the following errors.

kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686  
-DEXPORT_SYMTAB -c ip_masq.cmake[3]: Entering directory
`/usr/src/linux-2.2.16/net/netlink'
make[3]: warning: -jN forced in submake: disabling jobserver mode.
make[3]: Entering directory `/usr/src/linux-2.2.16/net/packet'
make[3]: warning: -jN forced in submake: disabling jobserver mode.
make[3]: Nothing to be done for `all_targets'.
make[3]: Leaving directory `/usr/src/linux-2.2.16/net/packet'
make[2]: Leaving directory `/usr/src/linux-2.2.16/net/packet'
make[3]: Nothing to be done for `all_targets'.
make[3]: Leaving directory `/usr/src/linux-2.2.16/net/netlink'
make[2]: Leaving directory `/usr/src/linux-2.2.16/net/netlink'
ip_masq.c:578: `ip_masq_hash' undeclared here (not in a function)
ip_masq.c:578: initializer element for `__ksymtab_ip_masq_hash.value' is
not constant
ip_masq.c:579: `ip_masq_unhash' undeclared here (not in a function)
ip_masq.c:579: initializer element for `__ksymtab_ip_masq_unhash.value' is
not constant
ip_masq.c:518: warning: `masq_port_lock' defined but not used
make[3]: *** [ip_masq.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.2.16/net/ipv4'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.2.16/net/ipv4'
make[1]: *** [_subdir_ipv4] Error 2
make[1]: Leaving directory `/usr/src/linux-2.2.16/net'
make: *** [_dir_net] Error 2

running gcc -v returns:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)


  Any help would be appreciated.

Comment 1 umkay 2000-12-02 03:12:39 UTC
I was able to successfully compile a kernel that had ip_Masquerading unchecked.

Comment 2 Michael Tokarev 2001-02-13 23:39:23 UTC
This is errata kernel, 2.2.17-14.
In ip_masq.c, there is a reference to ip_masq_hash() and ip_masq_unhash()
routines in EXPORT_SYMBOL() statements that are at a top of this file, but
those routines defined in a middle and not declared anywhere.  Both of this
are strange: usually exporting is done at a bottom of a file, and a routine
that are accessed by other modules (in this case, that are
ip_masq_{generic,ipsec,pptp}()) should be declared in some header file...

Aha -- found it.
In ip_masq.c, there is a code:
 #ifdef CONFIG_IP_MASQUERADE_MOD
 #include <net/ip_masq_mod.h>
 #endif
In that header that routines are declared.  So, we either should build
with CONFIG_IP_MASQUERADE_MOD (as a workaround), or, better, wrap those
two EXPORT_SYMBOLs using this same #ifdef.  Basically this is wat I do
now.

Btw, probably we'll live with this bug for 7.0 lifetime - I'm almost shure
that RedHat will not release new 2.2 kernel for 7.0... :(

Comment 3 Michael Tokarev 2001-02-13 23:42:03 UTC
Why there is no option for non-reporter to change some other fields? :)
(just kidding)

This issue isn't i386-specific.

Comment 4 Michael Tokarev 2001-02-13 23:54:28 UTC
Ok, one more info on this.  There is already a fix for a patch:
linux-2.2.17-ip-masq-vpn-fix.patch that fixes some issues in
linux-2.2.16-ip-masq-vpn.patch (this issue was introduced in
the latter).  This error occurs only when NOT using vpn features.
So, for umkay (and for me), solution will be to comment
out patches 251 and 252 (the two above ones) in spec file... :)

Comment 5 josip 2001-02-15 03:42:10 UTC
I ran into the same problem:

ip_masq.c:578: `ip_masq_hash' undeclared here (not in a function)
ip_masq.c:578: initializer element for `__ksymtab_ip_masq_hash.value' is not
constant
ip_masq.c:579: `ip_masq_unhash' undeclared here (not in a function)
ip_masq.c:579: initializer element for `__ksymtab_ip_masq_unhash.value' is not
constant
make[3]: *** [ip_masq.o] Error 1


Comment 6 Arjan van de Ven 2001-02-15 16:59:58 UTC
Can you attach your .config file that breaks? That makes it simpler
to reproduce (and verify it is fixed later)

Comment 7 Michael Tokarev 2001-02-15 17:33:34 UTC
This will happen only if CONFIG_IP_MASQUERADE_MOD is NOT defined.
Trivially...  By default, in Redhat's configs, this variable IS
defined. (and ofcouse, for ip_masq to be compiled at all, other
config_MASQ etc should be set to yes).  I already proposed a solution
to this (I don't like patches for patches) -- to wrap those two
EXPORT_SYMBOLs with the same #ifdef as #include above (clean way), or
just remove first ifdef (a bit dirty).  This is a "bug" in
ip_masq-vpn.patch - in  quotes here ("), as obviously if one applied
that patch he wants that functionality (controlled, among others, by
IP_MASQUERADE_MOD option).


Comment 8 Arjan van de Ven 2001-02-15 19:16:57 UTC
A patch for this will be in the next 2.2 kernel-build, if and when
one becomes available.

Comment 9 Ned Ulbricht 2001-02-26 09:56:41 UTC
*** Bug 29384 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.