| Summary: | [ assigned --> plasmaroo ] gentoo-sources-2.4.20-r7 compilation fails in net/ipv4/netfilter/ip_nat_core.c | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Phil Richards <news> |
| Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gcc-porting |
| Priority: | High | ||
| Version: | 1.4 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Something is strange with your portage tree, for this patch was in a long time ago. emerge --sync ... and remerge gentoo-sources ... and recompile if needed ... The "something strange in my portage" is that somebody changed the ebuild without bumping the ebuild version. I had unpacked r7 a while back (pre my installing gcc3.3). Since the version number hadn't changed I had no reason to expect that I would have to re-emerge the sources. Why should I? That's what version numbers are for... This either (a) a problem with people maintaining the ebuild not bumping the revision numbers when they should; or (b) the ebuild system not highlighting that my installed ebuild is out-of-date against the portage version. I can understand why "trivial" changes do not result in an automatic version increment, so *my* feeling is that (b) is more the issue. Oh well, given that that majority of my installations have had their ebuilds changed since they were installed, I suppose I should have guessed... Thanks anyway. We do not bump the version because these are minor fixes and only afflict a small variety of people. We *do* bump version numbers when needed. And portage never does reflect packages going out of date by date, but by version number. But if we did that, too many people would remerge the sources and it would cause horrendous headaches. Yeah, I think I said that, didn't I? My "issue" is that there is no way from the current portage stuff to find out that an ebuild has been changed in portage even though you have already installed it. Normally it isn't a problem - kernel sources probably *is* the only place it is one (although I've had problems in the past with other ebuilds that have been solved by a re-emerge of the same package I've had installed because a patch has been added that changes runtime behaviour). I think the problem is more fundamental in portage - and, no, I can't think of a good solution :-) Possibly one of the problems is that I use ~x86 and hence frequently install packages which get fixes added to the same ebuild revision after I've installed them. I don't really want to drop out of using ~x86 - I do try to log bug reports - but this type of issue is, well, an issue with participating in helping bleeding-edge ebuilds. Not a bit issue - I'll just automate my "check my whether my ebuilds are out of date in a non-trivial way" scripts... we *should* be bumping revision numbers when any change is made. Thats what they are for.. They are there for *non-trivial changes*. These changes are trivial and don't affect a large userset. Large GCC3.3 patching for the mainstream:- Yes, new revision. A little patch to get grsecurity to not screw things up when it's disabled is a minor thing, and I don't want users remerging and recompiling their kernel every week because of some patch they don't even take advantage of. I agree with everybody :-) There is a problem whatever approach is taken: don't bump the version number and people like me get confused; bump the version number and people like me get p*ss*d off with continually recompiling. (And we would all have a lot of problems if KDE version got bumped repeatedly.) Anyway, in the current form of things, *I'm* happy with the way things are being done - I'll just remember next time to double check the ebuilds haven't changed :-) |
Trying to compile kernel, fails with: [...] gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-gentoo-r7/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.20-gentoo-r7/include/linux/modversions.h -nostdinc -iwithprefix include -DKBUILD_BASENAME=ip_nat_core -c -o ip_nat_core.o ip_nat_core.c ip_nat_core.c:854:40: missing terminating " character ip_nat_core.c:855:49: missing terminating " character ip_nat_core.c:1038:1: unterminated argument list invoking macro "DEBUGP" ip_nat_core.c: In function `do_bindings': ip_nat_core.c:854: error: `DEBUGP' undeclared (first use in this function) ip_nat_core.c:854: error: (Each undeclared identifier is reported only once ip_nat_core.c:854: error: for each function it appears in.) ip_nat_core.c:854: error: syntax error at end of input ip_nat_core.c:833: warning: unused variable `helper_called' ip_nat_core.c:832: warning: unused variable `ret' ip_nat_core.c:786: warning: unused variable `is_tcp' ip_nat_core.c:70: warning: `ip_nat_cleanup_conntrack' defined but not used make[2]: *** [ip_nat_core.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.20-gentoo-r7/net/ipv4/netfilter' make[1]: *** [_modsubdir_ipv4/netfilter] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-gentoo-r7/net' make: *** [_mod_net] Error 2 The problem is that there is an string broken across two lines at net/ipv4/netfilter/ip_nat_core.c:854. This patch fixes it... --- net/ipv4/netfilter/ip_nat_core.c.old 2003-10-17 16:35:21.000000000 +0100 +++ net/ipv4/netfilter/ip_nat_core.c 2003-10-17 16:35:27.000000000 +0100 @@ -851,8 +851,7 @@ if (exp_for_packet(exp, pskb)) { /* FIXME: May be true multiple times in the * case of UDP!! */ - DEBUGP("calling nat helper (exp=%p) for - packet\n", exp); + DEBUGP("calling nat helper (exp=%p) for packet\n", exp); ret = helper->help(ct, exp, info, ctinfo, hooknum, pskb); if (ret != NF_ACCEPT) {