uccjcm@uncecs.edu (John McLendon) (03/01/90)
In article <681@mmlai.UUCP> burzio@mmlai.UUCP (Tony Burzio) writes: >In article <WAYNE.90Feb19124127@dsndata.uucp>, wayne@dsndata.uucp (Wayne Schlitt) writes: >> In article <680@mmlai.UUCP> burzio@mmlai.UUCP (Tony Burzio) writes: >> > but I truly don't believe that V7 actually exists, just the manuals >> >> and then wanted to know if they should install it. we had to tell >> them no 'cause we have no idea what, if any, problems our software >> will have on the new release. *sigh*. you would think that software >> developers could get the releases first... > >From past experiences, I expected that V7 would not break any 3rd party >software, but this seems to be incorrect this time. My sales rep and >local SE are comming by today to discuss the update (sounds >ominous). I DO know that LISP doesn't work under V7 on the 300s (of >course, from the number of bug reports that our local LISP hacker has >put in recently, I expect the problem is that LISP didn't work so well >to begin with :-) Well.... We installed it a week ago, on a third party SCSI disk (first time I've tried this!!!). Everything pretty much seems to work ok. The ANSI-C compiler is NOT included yet. The response center said to wait a month or so. We actually got uucp up and running in two days or so... Not too bad for a coupla virgins. We also managed to completely fake out the lp spooler and hang the laserjet off a cnode; no way to do this with the trailblazer. I'll be glad to publish our hack if there's enough interest... We're actually using the spooler directly! Motif is just like the 1.0 OSF distribution as far as I can tell except that the mwm cursors (hourglasss, etc..) are twice as big. Also, the mwm.h and MwmUtil.h includes are missing. The HP widget set doesn't want to handle cascades properly with mwm, but the hpwm included works just fine. I was able to bring up our old X11R2 application using the HP widget set by using a -lXtR2 compile option to cc and a -I/usr/include/XtR2 to get the old Core.h and stuff. The X windows performance is definitely better. We do get whines from the compiler about SIGCLD being redefined when including <sys/signal.h>, but to no effect. Mkmf complains vociferously about not finding things of the form ../h/xxxx.h on those same <sys/xxxx.h> includes. We also get complaints from ld of the form "Possible floating point incompatibility, recompile with +O1 option." Anyone know what this is about? We're running plain-jane 360/370's using the cc -g option. There's a scsi tape driver included in /usr/lib/drivers. Does anyone know if it works? All-in-all, I'm pleased with the better X performance. Things are running pretty smoothly. No crash and burns yet. I've got five cnodes on a single server (I know, i know). Of course, we don't use third party stuff, we write third party stuff. Obviously, I'm going for it. I expect the whines about includes to go away once I learn the incantation from the as yet unreceived PE manual set. Hope this helps... John -- Signed: John McLendon uunet\ - or - uunet!wgate.UUCP!jcm (919) 846-7931 (home) >mcnc!ecsvax.uncecs.edu!uccjcm (919) 941-5730 (play) gatech/
fkittred@bbn.com (Fletcher Kittredge) (03/01/90)
In article <1990Mar1.005350.5060@uncecs.edu> uccjcm@uncecs.edu (John McLendon) writes: >The ANSI-C compiler is NOT included yet. The response center said >to wait a month or so. We actually got uucp up and running in two Are you sure this is the case? We got 7.0 months ago and it had the ANSI C compiler. Remember, the default behavior is not to use ANSI C, you have to run the compiler with the -Aa switch. regards, fletcher Fletcher E. Kittredge fkittred@bbn.com
mjs@hpfcso.HP.COM (Marc Sabatella) (03/02/90)
>We also get complaints from ld of the form "Possible >floating point incompatibility, recompile with +O1 option." >Anyone know what this is about? We're running plain-jane 360/370's >using the cc -g option. What happened was that the floating point register save/restore conventions changed between 6.2 and 6.5, to satisfy the global optimizer. We put a mark in each object file to say if it uses the old or new conventions; most importantly, we put a mark on those new files which not only support the new conventions, but depend on routines that it calls to support them as well. If the linker sees one of the latter object files, and one that was compiled pre-6.5, it complains, since it is possible a routine in the new object file may call a routine in the old object file (directly or indirectly) and thus be messed up since the old routine didn't save/restore the necessary registers. Since you say you are compiling things "-g", that implies not "-O", so you don't have any of the code that requires other modules to use the new conventions. Similarly, since you are recompiling under 7.0, you don't have any of the code that uses the old conventions. Thus it must be some libraries you are using. The easiest way to tell what is going on is to pass "-v" to the linker (via "-Wl,-v" if you are using the compiler driver to perform the link). It will spit all sorts of information at you. You are looking for a line which says something is "version 0" (meaning old conventions) and another saying something is "version 3" (meaning it requires things it calls to use new conventions). Your modules should all be coming out "version 2", meaning they support the new conventions, but do not depend on things they call to do the same. Once you find the offending 0's and 3's, your workaround is to either recompile the things that were "3" using "+O1" (or no optimization at all), which will turn them back into 2's; or to recompile the things that were 0 using any options you want, so they will become anything but 0. Note that just because you optimize something ("-O"), that doesn't mean it will come out 3; it will still come out 2 unless it actually makes a lot of use of floating point. -------------- Marc Sabatella (marc%hpfcrt@hplabs.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
mev@hpfcso.HP.COM (Mike Vermeulen) (03/02/90)
>> The ANSI-C compiler is NOT included yet. The response center said >> to wait a month or so. We actually got uucp up and running in two > Are you sure this is the case? We got 7.0 months ago and it had the > ANSI C compiler. Remember, the default behavior is not to use ANSI C, > you have to run the compiler with the -Aa switch. An ANSI C compiler was released with HP-UX 7.0 for the series 800. An ANSI C compiler was not released with HP-UX 7.0 for the series 300. A s300 ANSI C compiler product can be ordered from the price list now, and should be shipping soon. --mev disclaimer-I just work in the lab and don't make official statements.
ken@hpubrcf.HP.COM (Ken Green) (03/02/90)
>>The ANSI-C compiler is NOT included yet. The response center said >>to wait a month or so. We actually got uucp up and running in two > >Are you sure this is the case? We got 7.0 months ago and it had the >ANSI C compiler. Remember, the default behavior is not to use ANSI C, >you have to run the compiler with the -Aa switch. ANSI-C is part of the 7.0 shipment for the 800 series only. The 300 series 7.0 does not have ANSI-C. Ken Green --ukcrc--
shankar@hpclscu.HP.COM (Shankar Unni) (03/03/90)
> In article <1990Mar1.005350.5060@uncecs.edu> uccjcm@uncecs.edu (John McLendon) writes: > >The ANSI-C compiler is NOT included yet. The response center said > >to wait a month or so. We actually got uucp up and running in two > > Are you sure this is the case? We got 7.0 months ago and it had the > ANSI C compiler. Remember, the default behavior is not to use ANSI C, > you have to run the compiler with the -Aa switch. The series 800 ANSI C compiler went out with 7.0. The series 300 compiler missed the boat, and is being released asynchronously, soon after 7.0. Both compile in K&R-compatibility mode by default, and require a switch (-Aa) to compile in ANSI-compliant mode. ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar DISCLAIMER: This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.
calwa@.bnr.ca (Kevin Chapman) (03/08/90)
In article <7370091@hpfcso.HP.COM> mev@hpfcso.HP.COM (Mike Vermeulen) writes: | |An ANSI C compiler was released with HP-UX 7.0 for the series 800. |An ANSI C compiler was not released with HP-UX 7.0 for the series 300. | |A s300 ANSI C compiler product can be ordered from the price list now, and |should be shipping soon. | How about an ANSI lint to go along with that compiler? Kevin Chapman uunet!bnrgate!bcarh13!calwa
mev@hpfcso.HP.COM (Mike Vermeulen) (03/09/90)
>|An ANSI C compiler was released with HP-UX 7.0 for the series 800. >|An ANSI C compiler was not released with HP-UX 7.0 for the series 300. >| >|A s300 ANSI C compiler product can be ordered from the price list now, and >|should be shipping soon. >| >How about an ANSI lint to go along with that compiler? The s300 ANSI C compiler product includes an ANSI lint and cxref (and cflow which comes for free because it calls the lint front end). The lint is produced from the same sources as the compiler (thus accepting ANSI syntax). In addition, lint has been enhanced to detect silent ANSI changes and to check prototype consistency and to check for lack of function prototypes. ANSI versions of lint and cxref are not available with HP-UX 7.0 series 800, but are planned for the future. --mev disclaimer: once again, not an official response.