pack@acdpyr.ucar.edu (Dan Packman) (12/22/88)
In OSX4.0, make doesn't properly update library elements such as
lib.a(foo.o)
This same construct in SUN OS4.0 properly finds the source file
(eg foo.c), recompiles it, archives the object file replacing
the old one, and then deletes the object file. Is this fixed in OSX4.4?
Dan Packman NCAR INTERNET: pack@acdpyr.UCAR.EDU
(303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET
Boulder, CO 80307 DECNET SPAN: 9.367::PACKscott@questar.QUESTAR.MN.ORG (Scott Anderson) (12/23/88)
In article <1160@ncar.ucar.edu> pack@acdpyr.UCAR.EDU (Dan Packman) writes: > In OSX4.0, make doesn't properly update library elements such as > lib.a(foo.o) > the old one, and then deletes the object file. Is this fixed in OSX4.4? Nope. I switched to the ATT make for those particular libraries. Quite anoying. Have not got this one in to RTOC yet, I have to put it on the waiting list behind all of the other broken things... 1/2 :-) -- Scott Anderson UUCP: scott@Questar.MN.ORG, Questar Data Systems ...!amdahl!bungia!questar!scott St. Paul, MN ATT: +1 612 688 0089
csg@pyramid.pyramid.com (Carl S. Gutekunst) (12/23/88)
In article <1160@ncar.ucar.edu> pack@acdpyr.UCAR.EDU (Dan Packman) writes: >In OSX4.0, make doesn't properly update library elements such as > > lib.a(foo.o) > >This same construct in SUN OS4.0 properly finds the source file.... RTFM, wrong universe. This facility does not exist in the 4.3BSD make(1), only the System V make(1). (Actually, there are some broken stubs in 4.3BSD make(1) for manipulating libraries, but they don't work as you'd like them to. SunOS 4.0 uses the System V make.) You can either compile your code in the att universe: att make or you can run the System V make in the ucb universe: ucb /.attbin/make Note, this type of question is pretty straight-forward, and is much better mailed to pyramid!bugs (RTOC) rather than being posted to the whole USENET. <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (12/23/88)
In article <1160@ncar.ucar.edu> pack@acdpyr.UCAR.EDU (Dan Packman) writes: >In OSX4.0, make doesn't properly update library elements... In article <1951@questar.QUESTAR.MN.ORG> Scott Anderson writes: >Nope. I switched to the ATT make for those particular libraries. > >Have not got this one in to RTOC yet.... And if you do, it will probably be returned from R&D with "user error." :-( The 4.3BSD make works exactly as it is documented to work. (If this is really important to you, though, by all means submit it as a bug anyway. You might be able to change someone's mind. :-)) This is a fundamental philosophical principle of the dual port: you don't go mixing features from the universes, even when those features are useful. The ucb make(1) doesn't extract libraries any more than the att vi does handling of SIGTSTP. Likewise, sockets aren't defined in the att universe, and shared memory operations aren't defined in the ucb universe. The justification for this is portability; if you write something that compiles and runs in the Pyramid's ucb universe, it will also compile and run on a 4.3BSD VAX. If you compile and run in the att universe, it will run on an SVR3 3B. If Pyramid's ucb make(1) allowed library extractions, you would now have a variation that was not portable to other systems. Of course, there is nothing from stopping you from using "/.attbin/make". But then it becomes glaringly obvious that you are doing something non-portable. I know a lot of people think that a "wall between the universes" is a pile of dingo's kidneys, and certainly what Sun started in SunOS 3.2 is its very anti- thesis. But a lot of other people (including me) who have to deal with a lot of different UNIX systems have found it to be a real life saver. <csg>
david@sun.com (more handsome than your average prawn) (12/24/88)
In article <52130@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >SunOS 4.0 uses the System V make. Wrong. SunOS 3.[2345] uses the System V make, with "SunPro make" optional in 3.[45]. SunOS 4.0 uses "SunPro make", with System V make exiled to /usr/old. Why am I reading comp.sys.pyramid?