Created attachment 311383 [details] build.log [ebuild U ] net-firewall/iptables-1.4.13 [1.4.12.1] USE="ipv6 -netlink -static-libs%" x86_64-pc-linux-gnu-gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DXTABLES_LIBDIR=\"/usr/lib64/xtables\" -DXTABLES_INTERNAL -I../include -I.. -I../include -Wp,-MMD,./.libxt_AUDIT.oo.d,-MT,libxt_AUDIT.oo -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -D_INIT=libxt_AUDIT_init -DPIC -fPIC -O2 -pipe -march=native -ggdb -o libxt_AUDIT.oo -c libxt_AUDIT.c; In file included from libxt_AUDIT.c:10:0: ../include/xtables.h:433:0: warning: "aligned_u64" redefined /usr/include/linux/types.h:13:0: note: this is the location of the previous definition libxt_AUDIT.c:89:2: warning: implicit declaration of function '__ALIGN_KERNEL' libxt_AUDIT.c:89:11: error: initializer element is not constant libxt_AUDIT.c:89:11: error: (near initialization for 'audit_tg_reg.size') libxt_AUDIT.c:90:19: error: initializer element is not constant libxt_AUDIT.c:90:19: error: (near initialization for 'audit_tg_reg.userspacesize') Portage 2.1.10.49 (hardened/linux/amd64, gcc-4.5.3, glibc-2.14.1-r3, 2.6.32-hardened x86_64) ================================================================= System uname: Linux-2.6.32-hardened-x86_64-AMD_Opteron-tm-_Processor_148-with-gentoo-2.0.3 Timestamp of tree: Thu, 10 May 2012 16:30:01 +0000 app-shells/bash: 4.2_p20 dev-lang/python: 2.7.2-r3, 3.2.2 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.30-r1 (virtual/os-headers) sys-libs/glibc: 2.14.1-r3 Repositories: gentoo x-portage ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native -ggdb" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-O2 -pipe -march=native -ggdb" FEATURES="assume-digests binpkg-logs collision-protect distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
your kernel headers are broken. upgrade them.
(In reply to comment #1) > your kernel headers are broken. upgrade them. We're using the latest stable headers for the 2.6.32 kernel which are in portage. Upgrading sys-kernel/linux-headers past 2.6.32 is not an option due to using a 2.6.32 kernel. We currently have strict dependencies on 2.6.32. As far as I can remember, sys-kernel/linux-headers-2.6.32 were removed from portage by Gentoo devs. So we're already using the latest headers applicable for this kernel and >=linux-headers-2.6.33 breaks our stuff, so this is out of the question. I think that iptables rather needs a DEPEND on >=linux-headers-SOME.VERSION. If you think that is not the case then I will certainly file another bug about the stable linux-headers-2.6.30 being broken or possibly suggest removing/masking all kernels and headers older than SOME.VERSION, if Gentoo obviously does not support the older but still stable versions of their ebuilds (a QA issue perhaps?).
linux-headers-3.1 is the latest stable kernel headers. there is no reason to force your system to use older versions.
(In reply to comment #3) > linux-headers-3.1 is the latest stable kernel headers. there is no reason > to force your system to use older versions. That's nonsense! There is clear sense in using the headers for the same version of the linux kernel I'm running. Just look at the differences between the headers between those two versions in the official linux/kernel/git/stable/linux-stable.git repository: git diff origin/linux-2.6.32.y..origin/linux-2.6.33.y include/ Also the kernel documentation at Documentation/make/headers_install.txt very clearly states the following: Kernel headers are backwards compatible, but not forwards compatible. This means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel. What more proof do you need about the obvious?
the C library handles backwards compat just fine i've expunged all linux-headers from the tree that are <3.1. thus any build not using 3.1 kernel headers is unsupported.
(In reply to comment #5) > the C library handles backwards compat just fine > > i've expunged all linux-headers from the tree that are <3.1. thus any build > not using 3.1 kernel headers is unsupported. Well actually its not just about the C library, but other programs directly using the linux kernel includes. So you MUST now also drop all <sys-kernel/*-sources-3.1 (some of them are stable, e.g. hardened-sources) because if people use an older kernel with newer linux-headers they will get into trouble. Older versions of kernels MUST be removed! It's the only way. At least finish the destruction you've started properly and let's get this over with! C'mon, SpanKY! :)
no, we don't. i run plenty of systems with 3.1+ headers but old kernels and have yet to hit a problem.
(In reply to comment #7) > no, we don't. i run plenty of systems with 3.1+ headers but old kernels and > have yet to hit a problem. Just because You haven't hit any problems, does not mean the problem does not exist, when it clearly does (as demonstrated above), only waiting to happen. Bugs on similar issues have been reported in the past, e.g. 407995, 398397, 396025, 376019, 369701, 368921 just to name some of the most recent ones. I think you can't guarantee that when keeping (and running on) hardened-sources-2.6.32.* and upgrading to >=linux-headers-3.1 I won't hit any bugs directly related to any API, ABI or version mismatch between hardened-sources-2.6.32.* and >=linux-headers-3.1. It's easy for you to do nothing and tell others to take all the risk... I won't reopen this bug this time, but Gentoo stable--
none of the examples you quoted are relevant. half of them were packages wanted new defines that they *optionally* utilized, and half resulted in version bumps and so the old ones no longer exist in stable and so wouldn't even support your active kernel regardless of the kernel headers utilized.
(In reply to comment #9) > none of the examples you quoted are relevant. The examples I quoted were relevant and could have been fixed by setting proper dependencies.
(In reply to comment #10) which has nothing to do with this bug report, or with talking about newer kernel headers not working with older kernels. the error you reported here was due to a bug in a specific kernel headers version (which happens all the time), so forcing a dependency in iptables on specific versions doesn't make much sense.
