jet@karazm.math.uh.edu ("J. Eric Townsend") (02/06/91)
Several times I've tried to port relatively innocuous (good word, eh?) code from the BSD/SunOS world to AIX 3.1 and have had a big AIX-shaped boot stomped all over my head. These are things that should be simple: patch, BSD tar, etc. So am I missing something? InfoHider has been of no use to me so far, and our printed manuals got lost somewhere, so I have to *rely* on InfoHider for any good bits I might need. Maybe there's a magic program, "bsdtoaix" that modifies generic BSD code so that cc/c89/xlc doesn't barf so hard. stats: 320, AIX 3.1 (rel 3002). -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2120 "It is the cunning of form to veil itself continually in the evidence of content. It is the cunning of the code to veil itself and to produce itself in the obviousness of value." -- Baudrillard
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (02/06/91)
In article <1991Feb6.020623.26983@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >Several times I've tried to port relatively innocuous (good word, eh?) >code from the BSD/SunOS world to AIX 3.1 and have had a big AIX-shaped >boot stomped all over my head. > >These are things that should be simple: patch, BSD tar, etc. > >[...] Maybe there's a magic >program, "bsdtoaix" that modifies generic BSD code so that cc/c89/xlc >doesn't barf so hard. Maybe this is self-evident, but you are compiling with -D_BSD and then linking everything to libbsd.a in the end, aren't you? I've compiled literally scores of more-or-less standard BSD programs this way (including patch, etc). After _BSD is defined, quite often the only problems remaining are declarations of malloc(), sprintf(), and the like, which can be safely #ifndef _AIX'd out of the source code. Also, I avoid xlc and c89 like the Black Plague. But that's another story. Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
jsalter@ibmpa.awdpa.ibm.com (02/07/91)
In article <1991Feb6.050344.1516@ux1.cso.uiuc.edu> andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) writes: >In article <1991Feb6.020623.26983@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >>Several times I've tried to port relatively innocuous (good word, eh?) >>code from the BSD/SunOS world to AIX 3.1 and have had a big AIX-shaped >>boot stomped all over my head. >>These are things that should be simple: patch, BSD tar, etc. patch doesn't come with the system, but it ports relatively easily. tar works just fine for me, and I transfer stuff all the time between 4.3's and 6000's. >>[...] Maybe there's a magic >>program, "bsdtoaix" that modifies generic BSD code so that cc/c89/xlc >>doesn't barf so hard. See the 'bsdcc' stanza in the BSD porting document /usr/lpp/bos/bsdport that comes with your system. It talks a LOT about this stuff. And, while you're at it, you might want to read the /usr/lpp/bos/README file which is chock-full [:-)] of interesting information. >Maybe this is self-evident, but you are compiling with -D_BSD and >then linking everything to libbsd.a in the end, aren't you? Don't forget that this has been upgraded in later releases from GOLD to also use the _BSD_INCLUDE token (for stuff that was missed earlier. They will be grouped together in later releases.) >I've compiled literally scores of more-or-less standard BSD programs >this way (including patch, etc). After _BSD is defined, quite often the >only problems remaining are declarations of malloc(), sprintf(), >and the like, which can be safely #ifndef _AIX'd out of the source code. >Also, I avoid xlc and c89 like the Black Plague. But that's another >story. Why? I don't understand this comment at all. xlc and c89 (as defined in the file /etc/xlc.cfg) just define *strict* ANSI C conformance. If your code is strictly conforming (nothing outside of the ANSI C standard) then it should compile just fine. If you believe your code is ANSI C compliant and it doesn't compile with xlc or c89, then you need to open an APAR/problem-report with IBM, or at least give us a chance to see the code. I'm sorry, but I'm tired of seeing global accusations like this without proof. >Marc Andreessen___________University of Illinois Materials Research Laboratory >Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl jim/jsalter IBM PSLOB, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter PS/2 it, or DIE! :-) The ramblings above have nothing to do with Big Blue.
andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) (02/07/91)
In article <1991Feb6.174248.14923@ibmpa.awdpa.ibm.com> jsalter@slo.awdpa.ibm.com (Jim Salter) writes: >>Also, I avoid xlc and c89 like the Black Plague. But that's another >>story. > >Why? I don't understand this comment at all. xlc and c89 (as defined in >the file /etc/xlc.cfg) just define *strict* ANSI C conformance. If your >code is strictly conforming (nothing outside of the ANSI C standard) then >it should compile just fine. If you believe your code is ANSI C compliant >and it doesn't compile with xlc or c89, then you need to open an >APAR/problem-report with IBM, or at least give us a chance to see the code. > >I'm sorry, but I'm tired of seeing global accusations like this without proof. Like I said, that's another story. What I meant was, there are very few programs ``out there'' that will compile with xlc/c89, which is obviously because most existing programs are K&R C, not ANSI C. Thus, I use cc when I port existing code rather than xlc/c89 (often even for code that looks ANSI-compliant, just because there's a better chance cc will compile it with few modifications). Marc -- Marc Andreessen___________University of Illinois Materials Research Laboratory Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl
jsalter@ibmpa.awdpa.ibm.com (02/07/91)
In article <1991Feb6.203350.5869@ux1.cso.uiuc.edu> andreess@mrlaxs.mrl.uiuc.edu (Marc Andreessen) writes: >Like I said, that's another story. What I meant was, there are very few >programs ``out there'' that will compile with xlc/c89, which is obviously >because most existing programs are K&R C, not ANSI C. Thus, I use cc >when I port existing code rather than xlc/c89 (often even for code that >looks ANSI-compliant, just because there's a better chance cc will compile >it with few modifications). That's the beauty of the the implementation. xlc, c89, and cc all invoke the same program. The *only* difference is the options passed to /usr/lpp/xlc/bin/xlcentry. You can define your own options or assembler or loader or loader options in /etc/xlc.cfg. The only shame is that you can't define which C pre-processor to use, though the BSD docs tell how to do that. Besides, if your program compiles under xlc or c89, you pretty much KNOW you're ANSI C compliant. :-) >Marc Andreessen___________University of Illinois Materials Research Laboratory >Internet: andreessen@uimrl7.mrl.uiuc.edu____________Bitnet: andreessen@uiucmrl jim/jsalter IBM PSLOB, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter PS/2 it, or DIE! :-) The ramblings above have nothing to do with Big Blue.