Build fixes for old Linuxes

Build fixes for old Linuxes

[Jan Engelhardt]

With this, iptables-1.4.17a (current git state) is tested to compile
and, to the degree covered by this patchset, to function under
Linux 2.4.27/glibc-2.3.2/Debian-3.1.

===
The following changes since commit 983196ceb4d3bb7b6d3cf6da18bb6d5a5eafb347:

  doc: document the -4 and -6 options (2013-01-07 02:26:16 +0100)

are available in the git repository at:

  git://git.inai.de/iptables old-linux

for you to fetch changes up to 1071ec54e6d7af406fe34afea1ce2c3e49ee1914:

  parser: workaround glibc-2.3.2 bug 358 (2013-01-15 19:16:55 +0100)

----------------------------------------------------------------
Jan Engelhardt (2):
      build: fix libiptc build failure on old linux-glibc-devel headers
      parser: workaround glibc-2.3.2 bug 358

 libiptc/linux_list.h   |    4 ++--
 libiptc/linux_stddef.h |    4 ++--
 libxtables/xtoptions.c |   14 ++++++++++++++
 3 files changed, 18 insertions(+), 4 deletions(-)

[PATCH 1/2] build: fix libiptc build failure on old linux-glibc-devel headers

[Jan Engelhardt]

On Debian 3.1, compilation of libiptc fails with

	  CC       libip4tc.lo
	In file included from libip4tc.c:113:
	libiptc.c:93: error: field `list' has incomplete type

This is because /usr/include/linux/list.h still existed at that time,
but has all its definitions stashed in __KERNEL__. Switching
linux_list.h's guards to another name resolves the problem.
---
 libiptc/linux_list.h   |    4 ++--
 libiptc/linux_stddef.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libiptc/linux_list.h b/libiptc/linux_list.h
index abdcf88..3a51185 100644
--- a/libiptc/linux_list.h
+++ b/libiptc/linux_list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _IPTC_LIST_H
+#define _IPTC_LIST_H
 
 #undef offsetof
 #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
diff --git a/libiptc/linux_stddef.h b/libiptc/linux_stddef.h
index 56416f1..57758c9 100644
--- a/libiptc/linux_stddef.h
+++ b/libiptc/linux_stddef.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_STDDEF_H
-#define _LINUX_STDDEF_H
+#ifndef _IPTC_STDDEF_H
+#define _IPTC_STDDEF_H
 
 #undef NULL
 #if defined(__cplusplus)
-- 
1.7.10.4

[PATCH 2/2] parser: workaround glibc-2.3.2 bug 358

[Jan Engelhardt]

glibc-2.3.2 has a bug whereby it would reject looking up services by
port number without a socket type specification. In iptables, this
manifests as:

	# iptables -A INPUT -p udp --sport 67
	iptables v1.4.16.3: Port "67" does not resolve to anything.

(The bug was found to be fixed in glibc-2.3.6.)
References: http://sourceware.org/bugzilla/show_bug.cgi?id=358
References: http://marc.info/?l=netfilter&m=135826543809613&w=2
Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---
 libxtables/xtoptions.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/libxtables/xtoptions.c b/libxtables/xtoptions.c
index 452e0fe..0654cb6 100644
--- a/libxtables/xtoptions.c
+++ b/libxtables/xtoptions.c
@@ -562,6 +562,20 @@ static int xtables_getportbyname(const char *name)
 	int ret;
 
 	ret = getaddrinfo(NULL, name, NULL, &res);
+	if (ret == EAI_SERVICE) {
+		/*
+		 * glibc-2.3.2 has a bug that yields EAI_SERVICE when
+		 * name is a number in string format, e.g. "67".
+		 * (http://sourceware.org/bugzilla/show_bug.cgi?id=358)
+		 * Fall back to strtoul if it is such a plain number.
+		 */
+		char *end;
+
+		ret = strtoul(name, &end, 10);
+		if (name != end && *end == '\0')
+			return ret;
+		return -1;
+	}
 	if (ret < 0)
 		return -1;
 	ret = -1;
-- 
1.7.10.4

Re: Build fixes for old Linuxes

[Pablo Neira Ayuso]

On Tue, Jan 15, 2013 at 07:20:00PM +0100, Jan Engelhardt wrote:
> 
> With this, iptables-1.4.17a (current git state) is tested to compile
> and, to the degree covered by this patchset, to function under
> Linux 2.4.27/glibc-2.3.2/Debian-3.1.
> 
> ===
> The following changes since commit 983196ceb4d3bb7b6d3cf6da18bb6d5a5eafb347:
> 
>   doc: document the -4 and -6 options (2013-01-07 02:26:16 +0100)
> 
> are available in the git repository at:
> 
>   git://git.inai.de/iptables old-linux
> 
> for you to fetch changes up to 1071ec54e6d7af406fe34afea1ce2c3e49ee1914:
> 
>   parser: workaround glibc-2.3.2 bug 358 (2013-01-15 19:16:55 +0100)
> 
> ----------------------------------------------------------------
> Jan Engelhardt (2):
>       build: fix libiptc build failure on old linux-glibc-devel headers
>       parser: workaround glibc-2.3.2 bug 358

Helping users is a noble thing from your side. However, that glibc
branch [1] and that debian release [2] are not maintained anymore.

[1] http://sourceware.org/glibc/wiki/Release
[2] http://www.debian.org/releases/sarge/

Sorry, I'm not taking this.

Re: Build fixes for old Linuxes

[Jan Engelhardt]

On Friday 2013-01-18 01:44, Pablo Neira Ayuso wrote:
>On Tue, Jan 15, 2013 at 07:20:00PM +0100, Jan Engelhardt wrote:
>> 
>> With this, iptables-1.4.17a (current git state) is tested to compile
>> and, to the degree covered by this patchset, to function under
>> Linux 2.4.27/glibc-2.3.2/Debian-3.1.
>
>Helping users is a noble thing from your side. However, that glibc
>branch [1] and that debian release [2] are not maintained anymore.

I kinda thought so. Was fun to look at it though.

So, what is the minimum {kernel, userspace} configuration that
we should require from users and which to put into INSTALL?
Do we still care about 2.4.x?

Re: Build fixes for old Linuxes

[Pablo Neira Ayuso]

On Fri, Jan 18, 2013 at 02:29:43AM +0100, Jan Engelhardt wrote:
[...]
> So, what is the minimum {kernel, userspace} configuration that
> we should require from users and which to put into INSTALL?
> Do we still care about 2.4.x?

As long as it is maintained, 2.4.x matters. Same thing with maintained
third party library dependencies.

Re: Build fixes for old Linuxes

[Jan Engelhardt]

On Friday 2013-01-18 03:06, Pablo Neira Ayuso wrote:

>On Fri, Jan 18, 2013 at 02:29:43AM +0100, Jan Engelhardt wrote:
>[...]
>> So, what is the minimum {kernel, userspace} configuration that
>> we should require from users and which to put into INSTALL?
>> Do we still care about 2.4.x?
>
>As long as it is maintained, 2.4.x matters. Same thing with maintained
>third party library dependencies.
>
Then the first patch should be applied.