Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.unix.aix
Subject: Re: xlc
Keywords: RS/6000 X11R3 xlc
Message-ID: <1990Sep3.215538.23444@athena.mit.edu>
Date: 3 Sep 90 21:55:38 GMT
References: <skidrow.652140292@ceres> <1990Sep2.220832.5992@athena.mit.edu> <1990Sep3.190213.3089@world.std.com>
Sender: daemon@athena.mit.edu (Mr Background)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 26

In article <1990Sep3.190213.3089@world.std.com> madd@world.std.com (jim frost) writes:
>jfc@athena.mit.edu (John F Carr) writes:
>>The other error was just 1501-230 without any other explanatory text.
>
>This sounds like the internal error you get when you set up bsdcc as
>mentioned in the bsdport document.  If you do this, remove the
>switches that tell it to use /lib/cpp.  That preprocessor internal
>errors if a #pragma alloca is contained in the source. 

I refuse to use "bsdcc" for the same reason I never use hc -Hpcc on the RT:
I believe in fixing the program, not the compiler (also, using bsdcc means
turning off some optimizations).

I think this is the stanza I used:
xcc:    use        = DEFLT
        crt        = /lib/crt0.o
        mcrt       = /lib/mcrt0.o
        gcrt       = /lib/gcrt0.o
        libraries  = -lc
        proflibs   = -L/lib/profiled,-L/usr/lib/profiled
        options    = -H512,-T512

(this is the default, except with strict type checking and read-only strings).

--
    --John Carr (jfc@athena.mit.edu)