Ian Lance Taylor <ian@xxxxxxxx> writes: > UUCP is GNU code which uses it. Sorry, I didn't know about it. > > > not every system supports SA_RESTART > > > > Which systems don't? That info would be good to add to the manual. > > I'm thinking of older systems. As far as I know SA_RESTART was > introduced by Solaris. I doubt it is in SVR4.2, for example, though I > admit that I don't have a way to check. Rich Stevens wrote in 1991 that SA_RESTART was in SVID Issue 3, in SVR4, and in 4.3BSD Reno. See: <http://groups.google.com/groups?selm=1991Jul31.185303.5583%40noao.edu> > I checked Ultrix 4.0, and it has sigaction but does not have SA_RESTART. That was released in 1990, right? It was probably based on 4.3BSD Tahoe then, and I guess Tahoe didn't have it. Reno came out in June 1990. > AC_DEFUN([AC_SYS_RESTARTABLE_SYSCALLS], > [AC_DIAGNOSE([obsolete], > [$0: System call restartability is now typically set at runtime. > Remove this `AC_SYS_RESTARTABLE_SYSCALLS' > and adjust your code to use `sigaction' with `SA_RESTART' instead.])dnl Perhaps that's a bit draconian. Can you suggest a better wording for that diagnostic? > Sure, but why is it obsolete? It's marked obsolete because of my survey. I didn't know of anybody that was using it correctly. (Bash was using it, but incorrectly.) Also, one big problem with AC_SYS_RESTARTABLE_SYSCALLS is that it doesn't work when cross-compiling. This is another reason to deprecate it. I notice that uucp guesses when cross-compiling. Wouldn't it be better for uucp to determine the value dynamically? That should be fairly easy to do, by running a bit of test code. Then you wouldn't need to guess, and you wouldn't need AC_SYS_RESTARTABLE_SYSCALLS either. (You would need an ancient system to test it on, but I guess if you have Ultrix 4.0 then that is ancient enough. :-) > For me I guess it's a philosophical issue. I think the point of > autoconf is to support a wide range of systems, including systems > which were created 10 years ago. For example, in 1992 I ported UUCP > to SVR2 systems which had been built in 1984; autoconf was very > helpful. Yes, but SVR2 was released in April 1984, so it's now nearly a 20-year old system. Nobody ports to SVR2 any more. Or to SVR3 (released 1986). These are all dead systems, outside of museums. Perhaps there are a few of them running production somewhere, but nobody ports software to them. Ultrix 4.0 is a bit newer, but it's pretty much dead as well. There are still a few hobbyists running ancient Ultrix 4.0 castoff hardware, I suppose, but the most recent report I found on Usenet of anyone trying to port software of any kind to Ultrix 4.0 was dated May 1998. Here it is: <http://groups.google.com/groups?q=%22Ultrix+4.0%22&selm=35225D0C.1D5EFCDD%40huntleigh.net> Five years of inactivity is a pretty good sign that the OS is dead, from autoconf's point of view. > What is the current autoconf philosophy? How old should systems be > before they are no longer supported? It's a judgment call, but basically if there isn't any serious usage outside of computer museums, then we shouldn't have to worry about it. > To put it another way, when can autoconf start using shell functions? We discussed this a few months ago; I vaguely recall that the consensus was that it's OK to use shell functions in new macros but we'll hold off converting the old stuff for a while. 'configure' scripts now try pretty hard to find a POSIX shell, even if /bin/sh isn't POSIX, so shell functions should be pretty safe.
