autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for help on improving the documentation


From: Russ Allbery
Subject: Re: Call for help on improving the documentation
Date: 22 Sep 2000 00:19:29 -0700
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

Greg A Woods <address@hidden> writes:
> [ On , September 21, 2000 at 18:37:09 (-0700), Russ Allbery wrote: ]

>>  * SysV systems (e.g. Solaris) often don't have hstrerror.

> hstrerror is part of libresolv and any system which has a libresolv too
> old to have hstrerror will likely have many many other resolver bugs
> too.

A lot of applications don't really care, though, provided gethostbyname
works reasonably well.  The other problem is that you don't want to link
with libresolv unless you need to, since it can break otherwise working
programs on some platforms (e.g. IRIX 5.3, from memory).

> Similarly the functions inet_net_ntop() and inet_net_pton() will be
> missing (they were introduced prior to BIND-4.9.5-P1 for goodness
> sake!!).

I think you mean inet_ntop and inet_pton, the replacements for inet_ntoa
and inet_aton that can deal with IPv6 addresses?  The only operating
system that I've seen that has those is BSDI (and probably other BSD
varients); Solaris didn't add them as supported functions until Solaris 8
if I remember right, and Linux glibc 2.1 doesn't seem to have them.

> The best solution for any application that needs DNS is to simply
> require that the user upgrade their resolver first (eg. install
> BIND-8.2.2-P5 or whatever's newest).

That's completely impractical in practice, at least in my opinion.  Taking
off the programmer hat and putting on the system administrator hat for a
moment, I would flatly refuse to install any software that required me to
replace Solaris 2.6's resolver library, which works just fine for what we
do with it.  I'd consider that to be unwarranted fiddling with the
operating system.

Anyway, apart from philosophy on that, the underlying theory of autoconf
appears to be to provide as much facilities for working around broken
systems as possible.

>>  * Some really old systems may not have getopt; I'm not sure which ones
>>    fall into that category.

> everything back to, and including, SysIII has getopt().  I don't think
> 4.2BSD had it, but it's in 4.3BSD for sure.  AT&T PD'd the code for one
> of their versions in 1985.

Ah, okay; INN has that for 4.2BSD portability, then (along with the mem*
stuff).  At some point, I'm likely to just drop portability to 4.2BSD (in
practice, I'm pretty sure we already have, given that we now require mmap
and I doubt 4.2BSD had it).

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]