kv@cae780.UUCP (Kumar Venkatramani) (10/05/90)
I just recently went in to Qualify our software on the DN400 machine running SR10.2 and saw something strange and wondered if anybody else had run into it. The file '/usr/include/string.h' is different on the DN400 than on the other machines!!(even though both machines are running SR10.2). Ordinarily I wouldn't have noticed but the new file causes memcpy() nad memcmp() to be multiply defined and a compile which used to work fails. (The two routines were defined in /usr/include/memory.h and continue to be defined there ) The other thing I saw was that the 'C' compiler version 6.7 behaved differently in that in was more picky. It reported warnings when there were characters after #endif, which does not occur on the 4500s or the 3500. If anybody else has seen these differences, and is aware of workarounds I would appreciate hearing from you.. As an aside, the 400 performed exceedingly well. We have a benchmark that is graphics intensive and memory intesive and the number for the 400/Sparcstation 1+/4500 were are follows: 5.27/6.0/9.50. I'm not sure these numbers mean much, but the interactive performance is very good compared to any other APOLLO boxes we have seen so far. Thanks in advance for your response. Kumar Venkatramani Comdisco Systems Inc. Foster City, CA 94404. INTERNET ADD: kv@csi.com UUCP ADD: ..!uunet!cae780!kv
vasta@apollo.HP.COM (John Vasta) (10/10/90)
In article <7361@cae780.UUCP> kv@csi.com (Kumar Venkatramani) writes: >I just recently went in to Qualify our software on the DN400 machine >running SR10.2 and saw something strange and wondered if anybody else >had run into it. > >The file '/usr/include/string.h' is different on the DN400 than on the >other machines!!(even though both machines are running SR10.2). Ordinarily >I wouldn't have noticed but the new file causes memcpy() nad memcmp() to >be multiply defined and a compile which used to work fails. (The two >routines were defined in /usr/include/memory.h and continue to be defined >there ) > >The other thing I saw was that the 'C' compiler version 6.7 behaved >differently in that in was more picky. It reported warnings when there >were characters after #endif, which does not occur on the 4500s or the 3500. It sounds like you're observing some differences between the bsd4.3 and sys5.3 environments. The sys5.3 version of string.h contains the memory function declarations but the bsd4.3 version doesn't. Also, the sys5.3 cpp warns about tokens following #endif, but the bsd4.3 version doesn't. Make sure you're in the environment you want to be when compiling your program. John Vasta Hewlett-Packard Apollo Systems Division vasta@apollo.hp.com M.S. CHR-03-DW (508) 256-6600 x5978 300 Apollo Drive, Chelmsford, MA 01824 UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta
system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (10/11/90)
In article <4d4d590d.20b6d@apollo.HP.COM> vasta@apollo.HP.COM (John Vasta) writes: >In article <7361@cae780.UUCP> kv@csi.com (Kumar Venkatramani) writes: >>The file '/usr/include/string.h' is different on the DN400 than on the >>other machines!!(even though both machines are running SR10.2). Ordinarily >>I wouldn't have noticed but the new file causes memcpy() nad memcmp() to >>be multiply defined and a compile which used to work fails. (The two >>routines were defined in /usr/include/memory.h and continue to be defined >>there ) > >It sounds like you're observing some differences between the bsd4.3 and >sys5.3 environments. The sys5.3 version of string.h contains the memory >function declarations but the bsd4.3 version doesn't. Also, the sys5.3 >cpp warns about tokens following #endif, but the bsd4.3 version doesn't. >Make sure you're in the environment you want to be when compiling your >program. The prototypes for 'strncpy' and 'strncat' are also missing (they are spelled 'strcpyn' and 'strcatn' on the SR10.2 Apollo systems). This may be bad news since these functions return "char *", not int; the proper type will not be used since the proper prototype doesn't exist. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775