Bug 21604 - Problem with ip_masq.c when compiling kernel
Problem with ip_masq.c when compiling kernel
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
: 29384 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-01 17:10 EST by umkay
Modified: 2007-04-18 12:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-15 12:33:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description umkay 2000-12-01 17:10:11 EST
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-01 22:12:39 EST
I was able to successfully compile a kernel that had ip_Masquerading unchecked.
Comment 2 Michael Tokarev 2001-02-13 18:39:23 EST
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 18:42:03 EST
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 18:54:28 EST
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@mtco.com (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-14 22:42:10 EST
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 11:59:58 EST
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 12:33:34 EST
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 14:16:57 EST
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 04:56:41 EST
*** 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.