Hi.
Sounds to me like the packages' problem. Do their authors simply not care about portability to non-IEEE floating point?
The problems are definitely with the packages. When I tried to talk with the python folks, for instance, they objected (well, a few of them) purely on the ideological ground that VAX is irrelevant, regardless of whether their assumptions are correct or whether embedded environments might have non-IEEE software floating point. The perl folks fixed things upstream.
What if we made sure all the soft-float stuff is in libm and compiled certain tools such as awk and selected pkgsrc packages to use software floating point?Do you mean software VAX FP or software IEEE FP? The latter sounds more consistent with the rest of your mail, but also sounds completely perverse for port-vax, not to mention, as you say, causing no end of trouble if less than the whole system is built that way.
I was thinking of VAX FP, but with software routines which would check for data that would trigger exceptions.
I think this would be a good way to fix some of these longstanding issues.I disagree. It wouldn't fix anything; it would merely paper over some of the worst of the portability bugs in the software in question.
I used the word "fix" without qualifying - you're right that it's not actually fixing as much as it's providing better behavior. If, for example, we had a "fixed" awk which doesn't dump core, pkgsrc would work a lot better, even if awk were slower.
I think the software should be fixed. If we (FWVO "we") don't have the human cycles for that, I think the broken tests should be disabled when building for VAX (or other non-IEEE FP) - or simply don't use the (broken) software in question.
For commonly used software, definitely. John