woan@exeter.austin.ibm.com (Ronald S Woan) (06/26/91)
In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: >I am one of the system admins at our company. One of our compiler folks >started using one of our rs6000's and had the following comments--- I suspect most of these things have to do with conforming to one standard or another and AIX 3.1's parentage. > * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch > command that I can find. What does arch do? Can't find it in the my Sys V or BSD references... > * Make on the rs6k doesn't seem to automatically sccs out files it can't > find, so you may need to sccs get SCCS. > > * The make on rs6k also doesn't automatically issue the .INIT rule. You might want to port over GNU make using the patches floating around on the net, though I don't remember .INIT rule support in it either. The AIX make seems to have the same SCCS support documented in the Nutshell book... Take a look at /etc/make.cfg. >* The rs6k like the u370 (that's the 3090) has no vfork(). It's in the BSD compatibility library (libbsd.a) according to the documentation. Anyway the BSD porting document in /usr/lpp/bos should help him out... -- +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan woan@cactus.org or woan@austin.vnet.ibm.com + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
cjr@ssi.UUCP (Cris J. Rhea) (06/27/91)
I am one of the system admins at our company. One of our compiler folks
started using one of our rs6000's and had the following comments---
seems easier to post and hope that someone in Austin will respond than
try to report all of these as problems/concerns.
--- Cris
uunet!ssi!cjr
ssi!cjr@uunet.uu.net
/* ---------- "That $%%^&# RS6000" ---------- */
Here are some crude porting notes on the software I got to port and test
out ok on the rs6k machines.
* Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch
command that I can find.
* Make on the rs6k doesn't seem to automatically sccs out files it can't
find, so you may need to sccs get SCCS.
* The make on rs6k also doesn't automatically issue the .INIT rule.
* Makefiles with blank lines that have tabs in them are treated as syntax
errors by the rs6k make utility.
* There is no /usr/lib/debug/malloc.o. Or at least I can't find it.
* On the rs6k cc does not define __STDC__ by default (unless you want
strict ANSI I guess) but the #include's and cc in general appears
to be an ANSI implementation. For example, it has stdlib.h, it wants
sprintf() to be declared as "int sprintf();" or not at all, and
it allows prototypes all the time.
The SVR4 cc has the attitude that strict ANSI mode defines
__STDC__ as 1 otherwise it defines it as 0, in either case it is
defined. Very inconsistent and annoying.
Similar problems were found with the mem*() functions and the
malloc()/free()/realloc()/calloc() functions, don't declare
them just use <stdlib.h> and <string.h>.
I almost tried a -D__STDC__=0 on the compile line, but chickened
out, maybe I'll try that some other time.
* Expect many warning messages about enum's, especially if used as bit
field types. This is stupid, if you can't use an enum as
a bit field that makes them even more worthless.
* The rs6k compiler objected to:
#define blah(a,,b) a+b
The sun doesn't seem to care.
* The rs6k compiler will demote formal parameters to the type they
are specified with, the sun does not, e.g.
a(f) float f; { }
inside a() the f parameter (even though it is passed the entire double)
will be truncated to a float before it is used. The sun cc
recognizes formal parameters with type float as being more
like doubles.
* Don't even attempt to declare any system calls if you include any
sys/*.h #include files. The chances of matching the declaration
in the #include is impossible and any include of any sys/*.h
#include file seems to bring in a whole nest of others, especially
unistd.h.
* The rs6k C compiler gives a warning error on every use of #ident.
Another warning message to ignore.
* The rs6k compiler complains about any macro that has been defined on
the compile line and also defined in the source, even if the
definitions are exactly the same. Yet another warning message to
ignore.
* The rs6k has defined NULL to be ((void*)0) instead of 0. This has
caused numerous fatal errors in some of the SVR4 sources.
Places where an unsigned or an ELF64_Addr (an unsigned) is
assigned NULL. I resorted to adding a -DNULL=0 to the compile
line to get around this.
* The rs6k like the u370 (that's the 3090) has no vfork().
* Somewhere in the include of sys/types.h I think, there are #define's of
the very popular names TRUE and FALSE. This cause problems in
SVR4 ld1 e.g. it has enum{TRUE=1,FALSE=0}Boolean; in it.
* The include of unistd.h includes just about everything, you may want to
avoid this file unless you really need it.
* The yacc source generated on the sun's will not compile on the rs6k,
you will need to re-run yacc on the rs6k to get rs6k acceptable
source. The sun yacc source declares things like malloc() wrong.
* SCCS: If you try and SCCS a file out on the rs6k that is older than
a year (I think), then sccs prints out a 4 or 5 line paragraph warning
you that the file you just sccs'd out is over a year old...
I guess this means that we should always be changing things, at least
once a year????brian@is.UUCP (Brian Zimbelman) (06/28/91)
In article (Cris J. Rhea) writes: > > I am one of the system admins at our company. One of our compiler folks > started using one of our rs6000's and had the following comments--- > seems easier to post and hope that someone in Austin will respond than > try to report all of these as problems/concerns. > > --- Cris > > uunet!ssi!cjr > ssi!cjr@uunet.uu.net > > /* ---------- "That $%%^&# RS6000" ---------- */ > > Here are some crude porting notes on the software I got to port and test > out ok on the rs6k machines. > > * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch > command that I can find. > > * Make on the rs6k doesn't seem to automatically sccs out files it can't > find, so you may need to sccs get SCCS. This looks like a user error to me. I have not had any problems getting make to retrive files from sccs. Granted I am not using any extensive make files, or a highly complex directory structure, but the basic grabing of files from sccs works fine. Has anyone other than this fellow verified these problems, or are you confident that this fellow is always correct? Brian Zimbelman ----------------------------------------------------------------------------- Innovative Solutions (505) 883-4252 3547 Colorado NE is!brian@bbx.basis.com Albuquerque, NM 87110 bbx.basis.com!is!brian
sef@kithrup.COM (Sean Eric Fagan) (06/28/91)
In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: > * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch > command that I can find. Most machines don't. It's very simple to write an arch command, though, and I've had to install one on lots of machines. Remember, folks, all the world's not a Sun. > * Make on the rs6k doesn't seem to automatically sccs out files it can't > find, so you may need to sccs get SCCS. Are you using SysV sccs convention (s.<filename>) or BSD (SCCS/...)? If you're not using the one that the builtin rule expects, I'm not terribly surprised it doesn't do what you want, and you shouldn't be, either. > * The make on rs6k also doesn't automatically issue the .INIT rule. What is this '.INIT' rule? I've never heard of it, and I've been using makefiles for half a decade now. > * Makefiles with blank lines that have tabs in them are treated as syntax > errors by the rs6k make utility. Blank lines with tabs tend to cause problems with make, and always have. > * There is no /usr/lib/debug/malloc.o. Or at least I can't find it. Not on my machine, either. There are several debug mallocs out there; the advantage being I can get source code if I want it, and, if it doesn't provide the amount of debugging I want, I can change it. > * On the rs6k cc does not define __STDC__ by default (unless you want > strict ANSI I guess) but the #include's and cc in general appears > to be an ANSI implementation. For example, it has stdlib.h, it wants > sprintf() to be declared as "int sprintf();" or not at all, and > it allows prototypes all the time. > The SVR4 cc has the attitude that strict ANSI mode defines > __STDC__ as 1 otherwise it defines it as 0, in either case it is > defined. Very inconsistent and annoying. > Similar problems were found with the mem*() functions and the > malloc()/free()/realloc()/calloc() functions, don't declare > them just use <stdlib.h> and <string.h>. > I almost tried a -D__STDC__=0 on the compile line, but chickened > out, maybe I'll try that some other time. Good for them! Doug Gwyn (among others) has a *lot* of objections to defining __STDC__ when you aren't compliant. I, personally, could argue both ways about it, and have done so before. But there is nothing wrong with what IBM did in that respect. > * Expect many warning messages about enum's, especially if used as bit > field types. This is stupid, if you can't use an enum as > a bit field that makes them even more worthless. I wish I had a copy of the ANSI C Standard handy; I think there might be good reason they did that. But I can't remember what ANSI said about bitfields. Ah, here it is (just found a copy): "a bit-field shall have a type that is a qualified or unqualified verson of one of int, unsigned int, or signed int." An enum type can *fit* into an int, but it is not necessarily an int. At least, that is likely IBM's reasoning. I will not say whether it is good or bad. > * The rs6k compiler objected to: > #define blah(a,,b) a+b > The sun doesn't seem to care. The sun compiler is broken. > * The rs6k compiler will demote formal parameters to the type they > are specified with, the sun does not, e.g. > a(f) float f; { } > inside a() the f parameter (even though it is passed the entire double) > will be truncated to a float before it is used. The sun cc > recognizes formal parameters with type float as being more > like doubles. The sun compiler is broken. You said it was a float, why are you surprised to find that it is? > * Don't even attempt to declare any system calls if you include any > sys/*.h #include files. The chances of matching the declaration > in the #include is impossible and any include of any sys/*.h > #include file seems to bring in a whole nest of others, especially > unistd.h. Any declarations in header files for any standard functions (i.e., those defined by ANSI and/or POSIX) must match the definition the standard says. Guess what: most of those don't necessarily match traditional declarations. For example, consider: extern int lstat(); /* pre-POSIX */ extern int lstat(const char *, struct stat *); /* POSIX */ If the latter is in a header file, but you use the former, that is an error. >* The rs6k C compiler gives a warning error on every use of #ident. > Another warning message to ignore. As it should. What is this "#ident"? Neither ANSI nor POSIX say anything about it. It would also, I suspect, complain about "#machine" or whatever the abortion SysVr4 uses is. >* The rs6k compiler complains about any macro that has been defined on > the compile line and also defined in the source, even if the > definitions are exactly the same. Yet another warning message to > ignore. This is legitimate, although it would be nice if it did check to see if they were the same. >* The rs6k has defined NULL to be ((void*)0) instead of 0. This has > caused numerous fatal errors in some of the SVR4 sources. > Places where an unsigned or an ELF64_Addr (an unsigned) is > assigned NULL. I resorted to adding a -DNULL=0 to the compile > line to get around this. Both definitions are correct. See ANSI. >* The rs6k like the u370 (that's the 3090) has no vfork(). vfork() is a hack, although, I will admit, it does have its uses. The only legitimate use of vfork() is that the child will execute before the parent. However, POSIX does not (yet?) have a vfork() like function; IBM may be waiting for POSIX to decide what to do before they add one. (POSIX did have, last time I checked a draft, a proposal for a 'qfork()' which was almost-but-not-quite vfork(). So be it.) >* Somewhere in the include of sys/types.h I think, there are #define's of > the very popular names TRUE and FALSE. This cause problems in > SVR4 ld1 e.g. it has enum{TRUE=1,FALSE=0}Boolean; in it. Neither should be there in ANSI or POSIX conformance mode (assuming the compiler has such a thing). However, I will say that I believe the SysVr4 one to be *wrong* in that respect, because what if someone else wants to define a boolean type? >* The include of unistd.h includes just about everything, you may want to > avoid this file unless you really need it. Again, there are limits on what <unistd.h> can include in POSIX conformance mode. >* The yacc source generated on the sun's will not compile on the rs6k, > you will need to re-run yacc on the rs6k to get rs6k acceptable > source. The sun yacc source declares things like malloc() wrong. Not a problem, really. I don't believe that yacc output is guaranteed to be portable. You should see if you can fix the yacc template, though. -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.
jfh@rpp386.cactus.org (John F Haugh II) (06/28/91)
In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: >* The rs6k like the u370 (that's the 3090) has no vfork(). I don't know which 3090 you are using, but AIX/370 support vfork(). >* SCCS: If you try and SCCS a file out on the rs6k that is older than > a year (I think), then sccs prints out a 4 or 5 line paragraph warning > you that the file you just sccs'd out is over a year old... > I guess this means that we should always be changing things, at least > once a year???? This is normal (and annoying) behavior. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
auvnele@auvsun1.tamu.edu (Eric L. Nelson) (06/28/91)
In article <116@is.UUCP> brian@is.UUCP (Brian Zimbelman) writes: >> * Make on the rs6k doesn't seem to automatically sccs out files it can't >> find, so you may need to sccs get SCCS. >This looks like a user error to me. I have not had any problems getting >make to retrive files from sccs. Granted I am not using any extensive make >files, or a highly complex directory structure, but the basic grabing of >files from sccs works fine. >Has anyone other than this fellow verified these problems, or are you >confident that this fellow is always correct? >Brian Zimbelman Have you actually gotten make to pull files from an SCCS directory? On my machine, it will only pull them if the s files are in the same directory as the .c files.(i.e. no SCCS directory). I'm still on 3003. what are you using? Eric Nelson
karish@mindcraft.com (Chuck Karish) (06/28/91)
In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: >I am one of the system admins at our company. One of our compiler folks >started using one of our rs6000's and had the following comments--- > > Here are some crude porting notes on the software I got to port and test > out ok on the rs6k machines. > > * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch > command that I can find. > > * Make on the rs6k doesn't seem to automatically sccs out files it can't > find, so you may need to sccs get SCCS. > > * The make on rs6k also doesn't automatically issue the .INIT rule. > > * Makefiles with blank lines that have tabs in them are treated as syntax > errors by the rs6k make utility. AIX isn't BSD and it isn't SunOS. Those constructs aren't available everywhere and makefiles that depend on them aren't portable. IBM could have adopted the approach that Convex did, and say "The customer is always right; let's give them a development environment just like their ond one". Convex restricted this to the VMS and Cray environments, though, on a 4.2->4.3 base. It would be madness to try to be backward compatible with everybody. > * There is no /usr/lib/debug/malloc.o. Or at least I can't find it. Isn't there a PD one available? I should look into this, myself. > * On the rs6k cc does not define __STDC__ by default (unless you want > strict ANSI I guess) but the #include's and cc in general appears > to be an ANSI implementation. It does if you invoke it as xlc. Just change $CC to 'xlc' in the makefiles. Unless, of course, 'cc' is hard-coded into the rules... > For example, it has stdlib.h, it wants > sprintf() to be declared as "int sprintf();" or not at all, and > it allows prototypes all the time. > The SVR4 cc has the attitude that strict ANSI mode defines > __STDC__ as 1 otherwise it defines it as 0, in either case it is > defined. Very inconsistent and annoying. Completely consistent with the ANSI/ISO C standard, though. A standard compiler #defines __STDC__ to be 1. If __STDC__ is #defined to be anything else, or is not #defined, you don't have a Standard C compiler. > Similar problems were found with the mem*() functions and the > malloc()/free()/realloc()/calloc() functions, don't declare > them just use <stdlib.h> and <string.h>. This behavior is required by POSIX.1. Declarations in line are permitted, but only if no POSIX.1-required headers are #included. > I almost tried a -D__STDC__=0 on the compile line, but chickened > out, maybe I'll try that some other time. If the code you're porting assigns a special meaning to the case where __STDC__ == 0, it's broken and should be fixed. Not an AIX problem. The #define would probably have worked. Any problems caused by doing this should be reported to IBM as bugs; their tests for __STDC__ in headers should be correct. > * Expect many warning messages about enum's, especially if used as bit > field types. This is stupid, if you can't use an enum as > a bit field that makes them even more worthless. An enum as a bit field? The C Standard doesn't make any guarantees about the size or alignability of an enum. This usage is risky. > * The rs6k compiler will demote formal parameters to the type they > are specified with, the sun does not, e.g. > a(f) float f; { } > inside a() the f parameter (even though it is passed the entire double) > will be truncated to a float before it is used. The sun cc > recognizes formal parameters with type float as being more > like doubles. C Compilers have always been free to do this. What's the point of having prototypes in the language if you insist on being able to contradict them? > * Don't even attempt to declare any system calls if you include any > sys/*.h #include files. The chances of matching the declaration > in the #include is impossible and any include of any sys/*.h > #include file seems to bring in a whole nest of others, especially > unistd.h. This is good advice. As I said before, it's required by POSIX.1. AIX 3.1.5 on the RISC System/6000 models 320 and 530 conforms to the POSIX.1 standard as measured by the NIST-PCTS. By default the namespace rules are more relaxed when you call 'cc', but the _POSIX_SOURCE macro does what it's supposed to. >* The rs6k C compiler gives a warning error on every use of #ident. > Another warning message to ignore. #ident isn't C, as far as I know. Should be a #pragma. >* The rs6k compiler complains about any macro that has been defined on > the compile line and also defined in the source, even if the > definitions are exactly the same. Yet another warning message to > ignore. I agree that this is annoying. >* The rs6k has defined NULL to be ((void*)0) instead of 0. This is covered in the FAQ for comp.lang.c, and is the topic of a shouting match now in progress in comp.std.c. The only portable use of NULL is to cast it to a pointer of the appropriate type. Code that requires that NULL == 0 is broken. Some systems use the (void *) cast when they don't have to, but it's a correct implementation of NULL. >* The rs6k like the u370 (that's the 3090) has no vfork(). AIX is not BSD. vfork() is a value-added performance hack, and should not be used (except inside #ifdefs) in programs that are intended to be maximally portable. It's perfectly reasonable for IBM not to provide vfork() if they don't think there's a significant perormance advantage. "#define vfork fork" should fix this. >* Somewhere in the include of sys/types.h I think, there are #define's of > the very popular names TRUE and FALSE. This cause problems in > SVR4 ld1 e.g. it has enum{TRUE=1,FALSE=0}Boolean; in it. Then #define _XOPEN_SOURCE and they'll go away. <curses.h> seems to #define TRUE and FALS unconditionally, though. >* The include of unistd.h includes just about everything, you may want to > avoid this file unless you really need it. As noted above, you need it for some forward declarations, which can't safely be done in line if you need any of the standard headers. Any header may #include any other header. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
nick@osf.org (Nick Dokos) (06/29/91)
In article <1991Jun27.221208.14845@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: In article <141@ssi.UUCP> cjr@ssi.UUCP (Cris J. Rhea) writes: ... >* The rs6k like the u370 (that's the 3090) has no vfork(). vfork() is a hack, although, I will admit, it does have its uses. The only legitimate use of vfork() is that the child will execute before the parent. However, POSIX does not (yet?) have a vfork() like function; IBM may be waiting for POSIX to decide what to do before they add one. (POSIX did have, last time I checked a draft, a proposal for a 'qfork()' which was almost-but-not-quite vfork(). So be it.) ... The original assertion that the rs6k has no vfork is false: vfork() is provided in the BSD compatibility library /lib/libbsd.a Nick Dokos (nick@osf.org) Systems Engineering (uunet!osf.org!nick) -- Nick Dokos (nick@osf.org) Systems Engineering (uunet!osf.org!nick)
brian@is.UUCP (Brian Zimbelman) (06/29/91)
In article <AUVNELE.91Jun28091305@auvsun1.tamu.edu>, (Eric L. Nelson) writes: > In article <116@is.UUCP> brian@is.UUCP (Brian Zimbelman) writes: > > >> * Make on the rs6k doesn't seem to automatically sccs out files it can't > >> find, so you may need to sccs get SCCS. > > >This looks like a user error to me. I have not had any problems getting > >make to retrieve files from sccs. Granted I am not using any extensive make > >files, or a highly complex directory structure, but the basic grabbing of > >files from sccs works fine. > > >Has anyone other than this fellow verified these problems, or are you > >confident that this fellow is always correct? > > >Brian Zimbelman > > Have you actually gotten make to pull files from an SCCS directory? > On my machine, it will only pull them if the s files are in the same > directory as the .c files.(i.e. no SCCS directory). I'm still on > 3003. what are you using? > > Eric Nelson First of all, I have not seen any differences in the way make works between releases. I have used make and sccs on 3.1.1 3.1.2 3.1.3 3.1.5, and many pre-release levels. So I don't think your level of the OS is a problem, anyone else know about any make/sccs bugs in different levels of AIX? Second, I haven't played with make/sccs on the RS6000's in over two months, so my memory is a little rusty, BUT what I was saying is that make DOES pull files out of sccs. I don't remember if the s. files were in the same directory, or in some other directory. Sorry. If you want me to look it up, I'll be playing with that in a few weeks, so email me, and I'll make a special effort. Sorry, I can't be more specific, but I don't want to mis-lead anyone. Brian Zimbelman -- ----------------------------------------------------------------------------- Innovative Solutions (505) 883-4252 3547 Colorado NE is!brian@bbx.basis.com Albuquerque, NM 87110 bbx.basis.com!is!brian
sef@kithrup.COM (Sean Eric Fagan) (06/29/91)
In article <678126129.18432@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >> I almost tried a -D__STDC__=0 on the compile line, but chickened >> out, maybe I'll try that some other time. >If the code you're porting assigns a special meaning to the >case where __STDC__ == 0, it's broken and should be fixed. Not >an AIX problem. The #define would probably have worked. Any >problems caused by doing this should be reported to IBM as >bugs; their tests for __STDC__ in headers should be correct. Chuck, I'm disappointed. __* is reserved for the implementation; if you define it at all, anything is allowed to happen. (See one of Henry Spencer's or Chris Torek's descriptions of what "anything" could mean.) -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.
benson@odi.com (Benson I. Margulies) (06/30/91)
You need to learn about the _ALL_SOURCE _POSIX_SOURCE _XOPEN_SOURCE and the _BSD* macros, and read the porting guide in /usr/lpp/bos. -- Benson I. Margulies