Jim Meyering wrote: > Since you listed Irix 6.2 and AIX 4.3.2 as being immune, I presumed > that versions earlier than those, yet with the same major number, > may be impacted.
Not necessarily. Simply, we don't have data about IRIX 6.1 and AIX 4.2. > If, as you now imply, all of 6.x and 4.x.x are > not affected by the removal of those modules, then it may be > less of a problem. The trouble is that it's hard to _know_. > What if there are other systems? We know pretty well. For 5 years, I've built up the database of function availability which we now have in the doc/*/*.texi files. Systems that are not in this list are systems which were active before 1997. > My concern is that package maintainers will address the warning > (remove those modules) without realizing that for minimal benefit they > are removing pieces that may make their project less portable to fringe > systems. It's not just "fringe systems". (I would use this term for OSF/1 4.0, HP-UX 11.00, Solaris 7, and the like.) It's the systems which did not ship with an ANSI C compiler. The systems where you cannot compile libiconv with -g because you either hit bugs in the assembler or otherwise fill up /tmp. > Not just old ones, but perhaps embedded ones, too, and they > would be unlikely to notice the regression right away. uClibc at least has all sorts of configuration options which allows the developer to include or exclude various functionalities. > A more conservative approach would be to make each of those > proposed-obsolete module AC_REQUIRE a new macro with code to run at > configure-time if ever the module is required. That code could make > configure fail by default with a diagnostic This approach would be good if we did not know about the possible portability problems. But our database in doc/* tells us. The functions we are talking about were apparently all part of ANSI C, and added by vendors in the years 1992-1994, in the scope of ANSI C compliance. Bruno
