🚀 go-pugleaf

dcook@spam.ua.oz (David Cook) writes:

>  I have tried compiling many programs obtained from the Net
>and other places on our Pyramid (a 9820, I believe, running OSx5.1),
>and I keep running into compatibility problems. For a start,
>is the ucb universe supposed to be _exactly_ like a BSD system ?

The main problem here is that "a BSD system" is a moving feast.  Originally,
the ucb universe in OSx was very close (_exactly_ leaves no margin for error)
to BSD 4.1 Unix (you have to remember this was a long time ago).  As BSD
has evolved through 4.2, Tahoe and 4.3 _many_ things changed, and the problem
was complicated by other popular operating systems offering BSD extensions
in a SVR3 base -- these systems convinced people that the environment was
like BSD, but whenever a conflict arose they chose SVR3 (hence string.h
and errno.h below). The upshot is that lots of code that is designed for a
BSD system is really designed for somebody's version of BSD at some point
in time.

By definition, Pyramid cannot make OSx compatible with all of these, and
changes to OSx have been driven by customer-demand, rather than any conscious
attempt to track the evolution of the BSD software base (note that with the
transition to SVR4 in DC/OSx, it is more than likely that new functionality
will be introduced there, rather than in OSx).

>In most cases, Makefiles will have a BSD option, and yet these
>programs fail to compile on the Pyramid. The most common errors 
>include : missing string.h ...

This is a SVR3-BSD incompatibility from way back, and it is preserved
right through to SVR4.  BSD originally had _only_ strings.h and SVR3
had _only_ string.h; if you have code developed in an environment
different to this, I'd suggest cross-linking the include files, e.g.
ln /usr/.attinclude/string.h /usr/.ucbinclude/include (which is
probably a bad idea, because code you develop may not compile
elsewhere) or force both include directories into cc's search path in
the desired order, e.g. -I/usr/.ucbinclude -I/usr/.attinclude

> ... and stdlib.h, ...

This has to do with ANSI C, not BSD.  The OSx C compiler understands prototypes
but does not have full ANSI pre-processor support.

> ... errno.h _doesn't_
>have an 'extern int errno' in it, where standard systems do, ...

This looks more like the SVR3-way.

>and the symbol 'BSD' is not defined by the compiler (although
>'pyr' is). ...

All bets are off in respect of predefined macros for cc.  The only sane way
is to explicitly force their definition through -Dname and wrap this up in
the makefile.

> There are other incompatibilities, but these
>are the ones that _always_ seem to occur (plus I can't remember
>the others at the moment :-)

I have probably ported more "BSD" code to OSx than almost anyone else, so
I understand the annoyance, however my experience has been than the blame
more often lies with the original code developer not understanding what
is, and what is not, BSD, and/or other operating system vendors having
substantially muddied the waters.

>  Are fixes to these problems in sight ? ('official' fixes
>from Pyramid, that is). Most programs, as yet, do not have
>a specific Pyramid option, and contacting the authors of
>all the programs that I attempt to compile to ask them to
>add Pyramid setup seems to be an effort-wasting option
>compared to having correct BSD operation on the Pyramid.

No Pyramid fix will happen unless someone opens a fault report -- but
given that this borders on a religious issue, Pyramid may well decide
that your "problem" is something they chose _not_ to fix (often
because it will break something else).

The weight of numbers suggests you will see little Pyramid-specific
code (that's the way it should be :-)), so you will have to apply
local changes.  In my experience this has required an effort that is
almost always inversely proportional to the value of the software.
-- 
Ken McDonell			  E-mail:     kenj@pyramid.com
Systems Technology Laboratory		      kenj@yarra.pyramid.com.au
Pyramid Technology Corporation	  Phone:      +61 3 521 3799
Melbourne, Australia		  Disclaimer: I speak for me alone, of course.