[ds6-devel] updated configure

[Chris Leishman]

On Tuesday, December 24, 2002, at 12:43 AM, Mauro Tortonesi wrote:
<snip>
>
> hi chris,
>
> 	as always, you've done an excellent work ;-) but i really wonder
> if the PROTO_INET6 macro as it is now really does make any sense. it 
> only
> checks if the constants PF_INET6 and AF_INET6 are defined by the 
> include
> files. if a system has those constants in its headers, it does not mean
> that it supports ipv6 (think of a glibc 2.2 linux system with a custom
> kernel where ipv6 support has been disabled).

Actually - checking that the headers have those components is the 
entire point of the check - NOT whether the system can actually create 
and use inet6 sockets.

All the checks for whether the system can create inet6 sockets have 
been moved to runtime, the PROTO_INET6 check is to just make sure we 
can compile the code.

For example, on a system that doesn't support inet6 (but does have the 
required types in the headers) getaddrinfo should never return INET6 
results (regardless of the hints).  This works for glibc2.2 and bsd 
afaik.  Unfortunately this is broken in glibc2.1 (it still returns 
inet6 results) - but to handle that I check the result of creating the 
socket and if I get a EPFNOSUPPORT error then I know the system can't 
actually create sockets of that type and those results get skipped.

> 	IMVHO, a macro that checks if the system supports PF_INET6 sockets
> by trying to create one (like the old IN6_ENABLE_IPV6 macro did) would 
> be
> more useful here. really, the best thing to do would be to write a 
> runtime
> check (a piece of C code like the one included in IN6_ENABLE_IPV6) to 
> find
> out if the system supports IPv6 (and in particular the creation of
> PF_INET6 sockets).

This is exactly what was there - and suffers from the problem that your 
embedding information on the run-time nature into the compiled version. 
  If someone changes the kernel, etc, then nc6 would also need to be 
recompiled to support the change (or remove support).  By doing the 
checks at runtime we avoid this (at a very small cost).

Basically, autoconf should only check the runtime nature of the system 
(eg. AC_TRY_RUN) when you really need to optimize for a particular 
situation, or when there's some really annoying behavior that can't be 
easily handled at runtime in the code, and should be avoided otherwise.

Hope that explains it somewhat.

Regards,
Chris