Makeing "Gated"

[Root Boy Jim]

In article <151385 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:
>In article <671136511.AA15442 at flaccid> keyvan at pyra.co.uk (Keyvan Shirnia) writes:
>>In article <1991Apr8.073344.2646 at cheops.qld.tne.oz.au> logier at cheops.qld.tne.oz.au (Rob Logie) writes:
>>>I am trying to make it under the UCB universe and it complains about
>>>not being able to find "memory.h"
>>
>>Well memory.h is only defined in ATT. (That is the definition) Some other
>>operating systems might have memory.h in their UCB environment, but that
>>is not true UCB!

The Tahoe distribution has memory.h.

>>I am not quite sure what kind of errors your are getting. However, the 
>>first thing I would try out would be: (Type this in your ATT universe shell)
>>
>>cc -I/usr/.attinclude -I/usr/.ucbinclude gated.c -o gated /.ucblib/libc.a
>>
>>This line should pickup both the UCB and ATT include files. From the linking
>>point of view, since you are already in ATT universe /.attlib/libc.a is
>>automatically searched. But to be sure that you are not missing any UCB
>>routines add /.ucblib/libc.a	.

I am surprised someone from Pyramid suggested this, as it doesn't work.
Pyramid put some nasty stuff to keep you from cross-linking.

>	In general, DON'T DO THIS! Cross universe linking can get very messy.

It's only messy because Pyramid made it so. I pulled out the memory
stuff, getopt, and some string functions from Sequent's ATT libc.a
and put them in the UCB libc.a because I was tire of dealing with it.

>If you do the above, for instance, you will get the ucb signal
>semantics. If your program expects the att semantics, then you're in
>trouble. This is widespread through the libraries - *printf and *scanf
>have subtle differences, malloc is a different algorithm, etc.

Using the return value from *printf and *scanf is nonportable.
Even if malloc is different, it should work either way.

>Doing
>the above (explicitly calling the ucb library) will cause all references
>that can be resolved from the ucb library to be. This is not supported,
>and can lead to very strange problems.

I agree that the librarys are linked in the wrong order. If someone
expects the att default behavior, the att lib should come first.

My situation was the exact opposite: I used "-lc /usr/att/lib/libc.a"
in the ucb universe on a Sequent.

>	Note that occasionally this will work fine. You might not
>get bitten. But it is simply wrong in the general case. Even extracting
>the necessary modules from the other universe's library can be a 
>problem - you need to check what referenced externals there are, and
>make sure they won't have problems in the other universe.

Yes, things can get tricky, but if one goes to all the trouble of
doings so, one should not be thwarted by the vendors.

>	We can get philisophical about whether it was better to stay 
>strictly compliant with the ucb and att standards, or to blend them
>together and get something that wouldn't necessarily be compliant
>with either.

We don't have to get philosophical; the answer is clear. Ten years
ago dual universes were kinda neat. You could satisfy people
from both camps on the same machine, and it was a marketing plus.

However, the world is moving towards a merged system. At least
half of the portability problems I see have to do with the
index/strchr or memcpy/bcopy dichotomy. Why not supply both?

The att and ucb environments are not so much universes as
galaxies within the same universe. At one end of the spectrum
is att, at the other, ucb. Real implementations are somewhere
in between, with features of both.

If you want a separate universe, make it a VMS one.

>Basically its a no win situation - for every customer
>that would like a blended environment, another would like one
>where their strictly compliant program would work.

This may have once been true. Better repoll your customers.
It has been said that there is no such thing as portability,
only programs that have been ported. Strict compliance
may also lead to tunnel vision.

Besides, which version of the standard is a program strictly
compliant with? I don't know how well Pyramid has kept up
with System V, but you are sure behind on BSD. You still
have 4.2 signals!

>The only true solution
>is a standard that encorporates both, and that is why we are so
>active with SVR4.

Well, you had better keep you eye on what Berkeley does too.
-- 
		[rbj at uunet 1] stty sane
		unknown mode: sane