21 Jun
2024
21 Jun
'24
10:24 p.m.
On 6/21/24 12:06 PM, Henry Bent wrote:
On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS
<tuhs(a)tuhs.org
<mailto:tuhs@tuhs.org>> wrote:
On 6/20/24 4:12 PM, ron minnich wrote:
For most projects, OS releases that ancient are not supported. It's the
code author using some base minimum for assumptions -- OSs from the past
35 years or so should be safe (dating from the 4.4 BSD release, to use
the strdup() example). Maybe that's the "code author not considering,"
but I'd say that's the result of the author simply not being interested
in something that old.
Bash ran on 4.3 BSD for a long time (and may still, I haven't checked with
that project maintainer in a while), and I ran bash-5.0 on OPENSTEP 4.2
because I like it, but I'd say those are exceptions.
I guess what I'm saying is that it's not the author's fault for not
wanting
to support OS versions released, for a significant percentage, before they
were born. They have different priorities.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
Personally, the autoconfig process does not fill
me with confidence,
and it
was recently responsible for a very serious
security problem. And,
autoconfig doesn't work: I've lost track of how many times autoconf has
failed for me. In general, in my experience, autoconf makes for less
portability, not more.
I'd be interested in some examples of this. I've had pretty decent
success
with autoconf-based portability.
I think it's important to make a distinction between autotools not working
and the actual software distribution not being buildable.
For example, I've recently been working with Ultrix V4.5. Most configure
scripts are able to complete successfully with ksh or sh5, so I don't
absolutely need bash (even though I do have it and use it). The
difficulties begin when trying to compile the actual code; for example,
Ultrix doesn't have strdup().