Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!eric
From: eric@pyramid.pyramid.com (Eric Bergan)
Newsgroups: comp.sys.pyramid
Subject: Re: Makeing "Gated"
Keywords: Gated
Message-ID: <151385@pyramid.pyramid.com>
Date: 9 Apr 91 23:14:02 GMT
References: <1991Apr8.073344.2646@cheops.qld.tne.oz.au> <671136511.AA15442@flaccid>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 53

In article <671136511.AA15442@flaccid> keyvan@pyra.co.uk (Keyvan Shirnia) writes:
>In article <1991Apr8.073344.2646@cheops.qld.tne.oz.au> logier@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"
>>
>>Has any one any ideas how to get around this (Pyramid seems to have memory.h
>>only in the att universe. If I try to compile under ATT I get a whole new
>>lot of problems) or better still if someone has some src/Makefile.* files
>>that are configured correctly for the Pyramid I would be greatfull if you
>>could mail them to me .
>
>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!
>
>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	.

	In general, DON'T DO THIS! Cross universe linking can get very
messy. 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. 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.

	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.

	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. 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. The only true solution
is a standard that encorporates both, and that is why we are so
active with SVR4.

-- 

					eric
					...!pyramid!eric