gjalt@eutesap13.es.ele.tue.nl (Gjalt de Jong) (07/14/89)
We would like to install gcc on our apollo DN3000 workstations. We already have the sources of gcc-1.32, but without machine dependent configuration files for apollo. Could someone provide us with these files. BTW, we would also like to run gcc on Alliant FX/8 and HP9000/835. Please mail (or post if you think that's more suitable) to gjalt@ele.tue.nl, since we have no access to the net for anonymous ftp (yet). Thanks in advance, -- __ Gjalt G. de Jong, | Phone: +(31)40-473345 Eindhoven University of Technology, Dept. of Electr. Eng. (ES/EH 7.26) P.O. Box 513, 5600 MB Eindhoven, The Netherlands Email: gjalt@es.ele.tue.nl
tomf@boulder.Colorado.EDU (FREDERICKS THOMAS M) (03/21/90)
When I try to compile gcc on my apollo 3500 everything works fine until it gets to the gnulib2 stuff. Here is where it errors: for name in _adddi3 _subdi3 _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _anddi3 _iordi3 _xordi3 _lshrdi3 _lshldi3 _ashldi3 _ashrdi3 _one_cmpldi2 _bdiv _cmpdi2 _ucmpdi2 _fixunsdfdi _fixdfdi _floatdidf; \ do \ echo ${name}; \ ./gcc -B./ -fstrength-reduce -O -I. -I. -I./config -c -DL${name} ./gnulib2.c -o ${name}.o; \ ar rc gnulib ${name}.o; \ rm -f ${name}.o; \ done _adddi3 ./gcc: installation problem, cannot exec as: No such file or directory *** Exit 1 Stop. What is the problem? Has anyone gotten this to compile on a 3500? I am running sr10.2 and 6.7 of the apollo C version if that helps. Thanks, Tom...
rtb@cernvax.UUCP (rainer tobbicke) (03/21/90)
In article <18645@boulder.Colorado.EDU> tomf@boulder.Colorado.EDU (FREDERICKS THOMAS M) writes: > When I try to compile gcc on my apollo 3500 everything works fine > until it gets to the gnulib2 stuff. Here is where it errors: > > .... > >./gcc: installation problem, cannot exec as: No such file or directory >*** Exit 1 >Stop. > What is the problem? Has anyone gotten this to compile on > a 3500? I am running sr10.2 and 6.7 of the apollo C version > if that helps. You should install the gnu assembler 'gas' as well. BTW, John Vasta from Apollo did it and also provides mods to generate COFF modules. See labrea.stanford.edu /pub/gnu/APOLLO.README and apollo-gcc-1.37.tar.Z I ran into a problem with this however: The gnu assembler deletes all symbols starting with a capital 'L', unless you explicitly tell it not to do so. So if you have a routine called 'LookupIDbyByte' as in X11R4.... You therefore better make sure that you add a 'L' in the config file tm-apollo68.h at the same place where you pass the 'C' for generating COFF object files. Good luck! Rainer Toebbicke, CERN, Switzerland
timv@cadfx.ccad.uiowa.edu (Timothy VanFosson,1405 EB,3355728,3518536) (03/21/90)
From article <18645@boulder.Colorado.EDU>, by tomf@boulder.Colorado.EDU (FREDERICKS THOMAS M): > > When I try to compile gcc on my apollo 3500 everything works fine > until it gets to the gnulib2 stuff. Here is where it errors: > . . (misc. stuff deleted) . > ../gcc: installation problem, cannot exec as: No such file or directory > Stop. > > What is the problem? Has anyone gotten this to compile on > a 3500? I am running sr10.2 and 6.7 of the apollo C version > if that helps. > GCC is attempting to invoke the Apollo assembler which, unless you've purchased it explicitly, is not on your machine. Your best bet is to get GAS running and use it. Timothy VanFosson E-mail : timv@cadfx.ccad.uiowa.edu Senior Systems Analyst US Mail : CAD-Research University of Iowa 228 ERF Phone : (319) 335-5728 Iowa City, Iowa 52242
cg377170@cygnus.uucp (Corey Gehman) (03/24/90)
>In article <18645@boulder.Colorado.EDU> tomf@boulder.Colorado.EDU (FREDERICKS THOMAS M) writes: > > >> When I try to compile gcc on my apollo 3500 everything works fine >> until it gets to the gnulib2 stuff. Here is where it errors: >> >> .... >> >>./gcc: installation problem, cannot exec as: No such file or directory >>*** Exit 1 >>Stop. > >> What is the problem? Has anyone gotten this to compile on >> a 3500? I am running sr10.2 and 6.7 of the apollo C version >> if that helps. .... >I ran into a problem with this however: The gnu assembler deletes all >symbols starting with a capital 'L', unless you explicitly tell it not to >do so. So if you have a routine called 'LookupIDbyByte' as in X11R4.... >You therefore better make sure that you add a 'L' in the config file >tm-apollo68.h at the same place where you pass the 'C' for generating >COFF object files. I also ran into the same problem and tried to solve it two different ways. First, I copied Apollo's 'as' into the directory and it "compiled" the library although it printed an warning something about unknown "C" flag. I then got gas compiled and then tried that. For both assemblers, I got the first stage gcc compiled but it couldn't compile itself to make the second stage. It wouldn't include 'stdio.h', I found that if I removed all of the "#attribute [aligned(1)]" in the file, it would at least include the file, but it still could not compile anything that worked. I don't remember exactly how it messed up here. I tried this about a month ago and gave up. I don't understand the stuff about capital 'L'. Could my problems be caused by that or is there something else wrong? Also can the working gnu 'cpp' include the standard 'stdio.h'? I'm on a 3500 with sr10.1 and 6.7 of Apollo C. Thank you, Corey ********************************** Corey Gehman cg377170@eng.clemson.edu
ran@cns.umist.ac.uk (Bob Nutter) (03/26/90)
Hi! (I'm new to this news game and news.announce.newusers isn't available, so bear with me if I mess up or beak some golden rule of etty-kitty...) In article <18645@boulder.Colorado.EDU> tomf@boulder.Colorado.EDU (FREDERICKS TH OMAS M) writes: > ... > What is the problem? Has anyone gotten this to compile on > a 3500? I am running sr10.2 and 6.7 of the apollo C version > if that helps. Installing gcc on apollos: ========== === == ======== This is how I went about installing gcc1.37 on our Apollo network (several 3000's and 4000's running sr10.1, and cc version 6.6). The stages below refer to the README file that come with John Vasta's (vasta@apollo.com) changes (see stage 1) I hope somebody may find it of use, other site's setups/software may mean you'll need to work it out for yourself. This is just what I had to do at ours. Stage 1 (obtain the software): -------- This is available from labrea.stanford.edu as /pub/gnu/APOLLO.README and apollo-gcc-1.37.tar.Z (as mentioned by Rainer Toebbicke in article <1662@cernvax.UUCP> rtb@cernvax.UUCP) You'll also need the gcc1.37 distribution, the gas1.34 distribution and bison. Stage 2 (adding changes): works ok ------- Stage 3 (building gas): ------- When you try to `make' gas you'll get an error in coff_convert.c, as it can't find the include file <apollo/mir.h>. This is because the include file is in /usr/include. I put a link in to keep things neat from /usr/include/apollo/mir.h to /usr/include/mir.h: ie: ln -s /usr/include/apollo/mir.h /usr/include/mir.h Once this is done, gas will install correctly. Then link `as' to the exectutable. Stage 4 (building bison): works ok ------- Stage 5 (building gcc): ------- This goes ok until you get to compiling `hard-params.c'. It is due to finding `volatile' at line 638 (etc). This *should* be ok, as we're compiling with `-A nansi' which *should* undef __STDC__ and thus define volatile as `static' like this: #ifndef __STDC__ #define volatile static #endif However, this doesn't seem to work (we've had loadsa problems with this, is /bin/cc brain-damaged anyone?) so do a quick hack and delete the ifdef/endif (or define volatile as static elsewhere). Once this is done, hard-params.c will compile. Stage 6 (testing): ------- The `make bootstrap CFLAGS=""' command (which tests gcc by getting it to compile itself) fails due to Domain/OS extensions to stdio.h. Basically, gcc doesn't like the `#attribute...' it finds early on. This one is an easy hack: edit stdio.h and use the fact that gcc defines CC to be `gcc' to conditionally select whether to use the #attribute extension. The start of stdio.h should then look something like this: . . . #if (CC == gcc) extern struct _iobuf { unsigned char *_ptr; short _cnt; unsigned char *_base; short _flag; short _file; } _iob[]; #else /*not gcc, this is what was there before*/ extern struct _iobuf { unsigned char *_ptr #attribute[aligned(1)]; short _cnt; unsigned char *_base #attribute[aligned(1)]; short _flag; short _file; } _iob[]; #endif . . . Once you've done this, the make bootstrap command runs to completion (plenty of warnings, but no errors). Remember to cahnge the stdio.h on every node that will run gcc. Once this has all been done you *should* have a working gcc. We haven't tried using it on anything major as yet, but at least it installed and things definitely compile and run. Good luck! bob --------------------------------------------------------------- bob nutter, computer officer Notice: The witty message dept. of computation UMIST is on holiday PO Box 88 Manchester M60 1QD UK tel: +44/0 61 200 3312 email: b.nutter@umist.ac.uk (pref) rn@ap.co.umist.ac.uk ran@cns.umist.ac.uk #include <std_disclaimer.h>
vasta@apollo.HP.COM (John Vasta) (03/28/90)
In article <1990Mar26.155315.29823@cns.umist.ac.uk> ran@cns.umist.ac.uk (Bob Nutter) writes: >Installing gcc on apollos: >========== === == ======== > >This is how I went about installing gcc1.37 on our Apollo network >(several 3000's and 4000's running sr10.1, and cc version 6.6). The >stages below refer to the README file that come with John Vasta's >(vasta@apollo.com) changes (see stage 1) > >Stage 1 (obtain the software): >-------- >This is available from labrea.stanford.edu as /pub/gnu/APOLLO.README >and apollo-gcc-1.37.tar.Z I believe that /pub/gnu/APOLLO.README only refers to Leonard Zubkoff's Emacs port. >You'll also need the gcc1.37 distribution, the gas1.34 distribution >and bison. > >Stage 3 (building gas): >------- >When you try to `make' gas you'll get an error in coff_convert.c, as >it can't find the include file <apollo/mir.h>. This is because the >include file is in /usr/include. I put a link in to keep things neat >from /usr/include/apollo/mir.h to /usr/include/mir.h: ie: > > ln -s /usr/include/apollo/mir.h /usr/include/mir.h > >Once this is done, gas will install correctly. Then link `as' to the >exectutable. Oops - it looks like mir.h has moved into /usr/include/apollo recently; I didn't realize it wasn't the same way "out there". >Stage 5 (building gcc): >------- >This goes ok until you get to compiling `hard-params.c'. It is due >to finding `volatile' at line 638 (etc). This *should* be ok, as >we're compiling with `-A nansi' which *should* undef __STDC__ and >thus define volatile as `static' like this: > > #ifndef __STDC__ > #define volatile static > #endif > >However, this doesn't seem to work hard-params.c is not compiled with -A nansi; the most recent release of the C compiler (6.7) handles volatile, etc. If you're using an earlier release, you can edit the gcc Makefile to set HARD_PARAMS_FLAGS = -A nansi >Stage 6 (testing): >------- >The `make bootstrap CFLAGS=""' command (which tests gcc by getting >it to compile itself) fails due to Domain/OS extensions to stdio.h. >Basically, gcc doesn't like the `#attribute...' it finds early on. I don't understand why everyone is having problems with this - my patch kit comes with a new version of the grammar file, c-parse.y, which handles this syntax. For some reason it isn't getting rebuilt; the timestamp in the tar file must be older than the files in the gcc distribution. To make sure it gets built, do "touch c-parse.y" after installing my changed files. Thanks for the assistance. John Vasta Hewlett-Packard Apollo Systems Division vasta@apollo.hp.com M.S. CHA-01-LT (508) 256-6600 x6362 300 Apollo Drive, Chelmsford, MA 01824 UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta
mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (02/15/91)
We just compiled sicstus Prolog for the Apollo with both /bin/cc and
gcc. While gcc offers some things which are A Good Thing for compiling
Prolog interpreters (like allocating global variables to registers),
the size command exposed a problem:
% size //hal/usr/local/lib/sicstus0.7*/E*/sp*
gcc: text(r) data(r/w) bss(r/w)
//hal/usr/local/lib/sicstus0.7-P3/Emulator/sp: 292 + 127736 + 1104 = 129882
cc: text(r) data(r/w) bss(r/w)
//hal/usr/local/lib/sicstus0.7/Emulator/sp: 168752 + 8616 + 1080 = 251862
Sizes per se (the sum of all sizes) are absolutely uninteresting,
but while cc allocates the program image to the read-only text section,
gas stores the stuff in in the r/w data section. Which - I think -
means that the image is not shareable (except if Apollo uses
fancy copy-on-write strategies - does anybody know this ?). Also,
this can lead to inadvertant program corruption:
main()
{
*((long *)main) - 0;
}
executes without protection violation - yuck !!
Has anybody found a workaround for this problem? Any hints will be
appreciated.
bye,
mike
Michael K. Gschwind, Institute for VLSI-Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door
mike@vlsivie.uucp 5-6-7-8 innovate don't litigate
e182202@awituw01.bitnet 9-A-B-C interfaces should be free
Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go!
Fax: (++43).1.569697