bakken@cs.arizona.edu (Dave Bakken) (07/13/90)
In article <99@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >In article <1990Jun29..185@rdk386.uucp> ron@rdk386.UUCP (Ron Kuris) writes: >> >>Why not just use gcc and not worry about the abnormalities of the "standard" >>compiler provided with Xenix? I agree its broken, but the compiler doesn't >>make the entire system unusable, especially when there are alternatives... > > This response is just a tad facile for my taste. GCC doesn't always > make life easier. I had my first encounter with GCC last week after > a colleague installed it on his Sequent Balance. Well, here was an > opportunity to see what all the fuss was about. Moved some of my > source over, checked flags and file locations, typed "make". > > Given my System V biases, tried compiling in the ATT environment. > Had to modify a few macro contructs to make them "ansi conformant", > but things got REAL interesting in the link/load phase. It just > couldn't find the c runtime module! Found the module in /.lib > (that damn universe again!). OK, back to BSD. Argh! Can't find > _regex, _strchr, ... > > Morale: GNU CC... It *might* work for you. Your problem here is not GCC but rather is DYNIX's retarded dual universes, which IMO is just a way of avoiding the task of integrating the two worlds, like virtually every other Unix vendor has done. Vendors have been providing this for many years, so much so that a lot of sources in comp.sources assume routines from both universes. These things compile with no problems, in general, on most systems, but it is a pain on DYNIX. This has been a pain for us when doing development work for our distributed programming language, SR, on a Sequent Symmetry running DYNIX. -- Dave Bakken Internet: bakken@cs.arizona.edu Dept. of Comp. Sci.; U.of Ariz. UUCP: uunet!arizona!bakken Tucson, AZ 85721; USA Bitnet: bakken%cs.arizona.edu@Arizrvax AT&T: +1 602 621 4098 FAX: +1 602 621 4246
mef@dbrus.uucp (Marv Fenner) (07/14/90)
In article <23002@megaron.cs.arizona.edu> bakken@cs.arizona.edu (Dave Bakken) writes: >In article <99@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: > >In article <1990Jun29..185@rdk386.uucp> ron@rdk386.UUCP (Ron Kuris) writes: > >> --- stuff about gcc deleted ---- > > > > Morale: GNU CC... It *might* work for you. > >Your problem here is not GCC but rather is DYNIX's retarded dual universes, >which IMO is just a way of avoiding the task of integrating the two worlds, >like virtually every other Unix vendor has done. Vendors have been providing >this for many years, so much so that a lot of sources in comp.sources As little as three years ago, no major Unix vendors (that I'm aware of) provided a truly merged SYSV/BSD environment. Dynix was one of several implementations designed to bridge the gap by offering the "best of both worlds" (others which come to mind are Pyramid, Harris, Siemens, Apollo). For its time, dual universality offered a way to develop portable software for a Unix community which consisted of everything from hard-core SYSV-forget-the-csh machines to pure BSD environments. Now that Sun, UI and OSF have done their thing, the trend toward integrated Unix has made (IMO) the dual-universe concept *obsolete* (s;dual universe;exception directories named 5bin, etc..;). >assume routines from both universes. These things compile with >no problems, in general, on most systems, but it is a pain on DYNIX. >This has been a pain for us when doing development work for our >distributed programming language, SR, on a Sequent Symmetry running >DYNIX. >-- I have worked with Dynix for two years, and overall, have found it to be an excellent development/maintenance environment. However, the "pain" you mentioned has plagued me also - in the form of kludgy build environments. ( One ex: -I/usr/include -I/usr/.include. Hey Sequent, are these headers mutually exclusive? ) >Dave Bakken Internet: bakken@cs.arizona.edu >Dept. of Comp. Sci.; U.of Ariz. UUCP: uunet!arizona!bakken >Tucson, AZ 85721; USA Bitnet: bakken%cs.arizona.edu@Arizrvax >AT&T: +1 602 621 4098 FAX: +1 602 621 4246 Marv Fenner (916)920-9092 | Opinions are mine; The terminal Unify Corp. Sacramento, CA | belongs to Unify mef@unify.UUCP ...!{csusac,pyramid}!unify!mef Marv Fenner (916)920-9092 | Opinions are mine; The terminal Unify Corp. Sacramento, CA | belongs to Unify mef@unify.UUCP ...!{csusac,pyramid}!unify!mef
guy@auspex.auspex.com (Guy Harris) (07/15/90)
>>Your problem here is not GCC but rather is DYNIX's retarded dual universes, >>which IMO is just a way of avoiding the task of integrating the two worlds, >>like virtually every other Unix vendor has done. Vendors have been providing >>this for many years, so much so that a lot of sources in comp.sources > >As little as three years ago, no major Unix vendors (that I'm aware of) >provided a truly merged SYSV/BSD environment. Dynix was one of several >implementations designed to bridge the gap by offering the "best of both >worlds" (others which come to mind are Pyramid, Harris, Siemens, Apollo). > >For its time, dual universality offered a way to develop portable >software for a Unix community which consisted of everything from hard-core >SYSV-forget-the-csh machines to pure BSD environments. > >Now that Sun, UI and OSF have done their thing, the trend toward >integrated Unix has made (IMO) the dual-universe concept *obsolete* >(s;dual universe;exception directories named 5bin, etc..;). The "dual universe" scheme and the "exception directories" scheme are generally *not* equivalent. "Dual universe" systems seem to by inclined towards building "brick walls" between the S5 and BSD environments, while the "exception directories" systems tend not to disallow access to "xargs" or "shmat()" from the BSD environment, or to "more" or "socket()" from the S5 one. There are those who prefer the former, perhaps because it means they don't get tempted to use stuff from the "wrong" environment. There are definitely those who prefer the latter; the original poster seems to be one of those, and that was the point he was trying to make by referring to "integrating the two worlds". Given that there are routines that behave differently, you can't merge them 100%, obviously. The fact that "signal()" behaves differently in the two environments doesn't mean you can't put "socket()" in the S5 environment or "shmat()" in the BSD environment, though (although, for whatever reason, you may decide not to). And as for what "Sun, UI and OSF" have done: well, SunOS isn't "truly merged" if you mean that it has one environment, but then neither is System V Release 4; it's similar to SunOS - or, probably, more like recent (or upcoming?) versions of IRIX, in that the "default" environment is the S5 one and any stuff in the BSD environment that's incompatibly different gets stuck in "/usr/ucbinclude" or some place like that; however, the *compatible* stuff generally ends up in *both* environments. Dunno what OSF plans to do, but I doubt they've figured out how to make "signal()", for instance, read the programmer's mind, or the "tr" command, so I suspect OSF/1 will probably be another of the "exception directories" systems.