jeff@stormy.atmos.washington.edu (Jeff Bowden) (09/02/88)
I grabbed the gcc executables a few days ago. I found that I had insufficient resources to run it (sob :-( ). I uploaded it to a local BBS, though. One person who downloaded it. This person has a quite bit of experience programming on the ST but I don't think he knows a lot about Unix. > 31Aug88 From Ganelius >I more or less have the GNU C compiler installed under MT C Shell. A major >problem though is the lack of the run time library. The library source was >compiled with something other than the GNU compiler, apparently. Is a >compiled library available? I ran into a couple of bugs in the compiler so >far. The compiler driver does not recognize the command line options `-c' and >`-o'. Also most of its console output is missing carriage-returns. > > Also, is a Unix compatible make utility available from GNU for the ST? Since can't run it I can't be of much immediate assistance. Does anyone here have suggestions? My guess is the MT C shell does command line arguments differently than gulam (the shell used by the guy who did the port). Perhaps it also does environment variables differently. (so the compiler merely can't find the library file as opposed to being unable to read it?) -- Jeff Bowden jeff@stormy.atmos.washington.edu
jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (09/06/88)
Date: 2 Sep 88 10:51:04 GMT
From: stormy.atmos.washington.edu!jeff@beaver.cs.washington.edu (Jeff Bowden)
I grabbed the gcc executables a few days ago. I found that I had
insufficient resources to run it (sob :-( ).
Yah, I was afraid that would happen. Please, everybody, read the blurb
file (GNUBLURB.TXT) before downloading it. It's just too big for random
copying around. The blurb contains a description of what's where, which
pieces of the distribution you'll need to do what, and what system
resources you'll need to run it. Help keep net traffic down!
I uploaded it to a local BBS,
though. One person who downloaded it. This person has a quite bit of
experience programming on the ST but I don't think he knows a lot about
Unix.
Neither do I; that shouldn't make a difference.
> 31Aug88 From Ganelius
>I more or less have the GNU C compiler installed under MT C Shell. A major
>problem though is the lack of the run time library.
The runtime library is in GNULIB.ARC, available from all the usual
servers.
The library source was
>compiled with something other than the GNU compiler, apparently.
That's wrong. The library was compiled with the GNU 1.23.
Is a
>compiled library available? I ran into a couple of bugs in the compiler so
>far. The compiler driver does not recognize the command line options `-c' and
>`-o'.
That's also wrong.
Also most of its console output is missing carriage-returns.
That's never happened to me.
>
> Also, is a Unix compatible make utility available from GNU for the ST?
I don't know how compatible it is with Eunuchs, but the GNU MAKE util is
in GNUUTILS.ARC.
Since can't run it I can't be of much immediate assistance. Does
anyone here have suggestions? My guess is the MT C shell does command
line arguments differently than gulam (the shell used by the guy who
did the port).
Yes, I'd guess that's true, but it's still a bit mysterious how it could
get as confused as he describes. Could it be that MT upcases command
lines before executing them?
I'd suggest he try it with gulam. Get it working that way first, then
see what it takes to make it work with other CLI's.
Perhaps it also does environment variables differently.
(so the compiler merely can't find the library file as opposed to being
unable to read it?)
That's possible as well. Still, from the text of his message, it sounds
like something didn't like the format of the OLB, not that it couldn't
find it.
I'm afraid more information is needed here.poole@forty2.UUCP (Simon Poole) (09/09/88)
In article <JEFF.88Sep2035059@stormy.atmos.washington.edu> jeff@stormy.atmos.washington.edu (Jeff Bowden) writes: >I grabbed the gcc executables a few days ago. I found that I had >insufficient resources to run it (sob :-( ). Gcc can be run on a 1 MB machine! You will not be able to compile any larger files from GULAM, but you can revert to compiling from the Desktop if memory is a problem. To bootstrap you NEED: a copy of gulam a diskeditor 1) patch the executable of gcc-cc1.ttp so that only 300 kB of stack instead of 500 kB are allocated (you can search for the value 500000, it only occurs once, somewhere around 364kB). [That you have to do this is really a bug, there is NO need for a GEMDOS only program, that doesn't exec another program to give memory back to GEMDOS, I'm changing my crt0 so that it will take -1L in _stksize to mean: "Don't do a Mshrink"] 2) Now throw all resident stuff out (accessories etc. just keep GEMBOOT or folderxxx (you do have a HD?)), start gulam and setup the enviroment as described by jrd. You should now be able to compile most programs (you can compile all of flex except parse.c and scan.c for an example). This is a good time to get the sources and extract the documentation from them, how else are you going to know about -mshort -fomit-frame-pointer etc.? 3) If a source file is too large to be compiled from GULAM, you will get a "no more virtual memory" message or someting like that (probably already from gcc-cpp). You can workaround this by running the compiler from the desktop, the current gcc.ttp will NOT work from the desktop (reasons follow), so you will have to write a small wrapper program to do this (I'm fixing gcc.ttp right now.....). Note: all gcc stuff assumes: file-handle 0 = stdin 1 = stdout 2 = stderr since the GEMDOS default for handle 2 is the serial port, this isn't much good when you start stuff from the desktop. So you need a Fforce(2,Fdup(1)) At the begining of your program to see any error output (and due to a bug in stdio to see any output at all). Trying this shows two bugs in the current runtime library: - Fforce has a wrong binding in osbind.h, it uses 3 short (aka 16 bit) arguments! Write a trap-1www function to do this. [BTW is anybody working on cleaning up the library, there is a lot of stuff that should be done] - stdout uses GEMDOS handle 2 instead of 1 (I haven't actually found the location of the bug yet, but the symptoms are (every thing from the desktop naturally.....): Works: Fwrite(1,..... Fforce(2,Fdup(1)); Fwrite(2,..... Doesn't work (first line doesn't get output): fprintf(stdout,"%s\n","Test of stdout"); Fforce(2,Fdup(1)); fprintf(stderr,"%s\n","Test of stderr"); Works: Fforce(2,Fdup(1)); fprintf(stdout,"%s\n","Test of stdout"); fprintf(stderr,"%s\n","Test of stderr"); Don't get put off by this description, GNC CC is worth it! (For the Turbo C people, there is a note in the manual about using registers for parameter passing in future versions......) -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
poole@forty2.UUCP (Simon Poole) (09/10/88)
In article <19880906162643.1.JRD@MOA.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: > >I don't know how compatible it is with Eunuchs, ^^^^^^^ One day, somebody is going to lock you up in a room with an IBM + MVS + JCL + TSO and throw the key away :-) -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
poole@forty2.UUCP (Simon Poole) (09/10/88)
[Seems as something zapped this the first time, sorry if it shows up twice] In article <JEFF.88Sep2035059@stormy.atmos.washington.edu> jeff@stormy.atmos.washington.edu (Jeff Bowden) writes: >I grabbed the gcc executables a few days ago. I found that I had >insufficient resources to run it (sob :-( ). Gcc can be run on a 1 MB machine! You will not be able to compile any larger files from GULAM, but you can revert to compiling from the Desktop if memory is a problem. To bootstrap you NEED: a copy of gulam a diskeditor 1) patch the executable of gcc-cc1.ttp so that only 300 kB of stack instead of 500 kB are allocated (you can search for the value 500000, it only occurs once, somewhere around 364kB). [That you have to do this is really a bug, there is NO need for a GEMDOS only program, that doesn't exec another program to give memory back to GEMDOS, I'm changing my crt0 so that it will take -1L in _stksize to mean: "Don't do a Mshrink"] 2) Now throw all resident stuff out (accessories etc. just keep GEMBOOT or folderxxx (you do have a HD?)), start gulam and setup the enviroment as described by jrd. You should now be able to compile most programs (you can compile all of flex except parse.c and scan.c for an example). This is a good time to get the sources and extract the documentation from them, how else are you going to know about -mshort -fomit-frame-pointer etc.? 3) If a source file is too large to be compiled from GULAM, you will get a "no more virtual memory" message or someting like that (probably already from gcc-cpp). You can workaround this by running the compiler from the desktop, the current gcc.ttp will NOT work from the desktop (reasons follow), so you will have to write a small wrapper program to do this (I'm fixing gcc.ttp right now.....). Note: all gcc stuff assumes: file-handle 0 = stdin 1 = stdout 2 = stderr since the GEMDOS default for handle 2 is the serial port, this isn't much good when you start stuff from the desktop. So you need a Fforce(2,Fdup(1)) At the begining of your program to see any error output (and due to a bug in stdio to see any output at all). Trying this shows two bugs in the current runtime library: - Fforce has a wrong binding in osbind.h, it uses 3 short (aka 16 bit) arguments! Write a trap-1www function to do this. [BTW is anybody working on cleaning up the library, there is a lot of stuff that should be done] - stdout uses GEMDOS handle 2 instead of 1 (I haven't actually found the location of the bug yet, but the symptoms are (every thing from the desktop naturally.....): Works: Fwrite(1,..... Fforce(2,Fdup(1)); Fwrite(2,..... Doesn't work (first line doesn't get output): fprintf(stdout,"%s\n","Test of stdout"); Fforce(2,Fdup(1)); fprintf(stderr,"%s\n","Test of stderr"); Works: Fforce(2,Fdup(1)); fprintf(stdout,"%s\n","Test of stdout"); fprintf(stderr,"%s\n","Test of stderr"); Don't get put off by this description, GNC CC is worth it! (For the Turbo C people, there is a note in the manual about using registers for parameter passing in future versions......) -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!poole Simon Poole BITNET: K538915@CZHRZU1A ----------------------------------------------------------------------------
david@bdt.UUCP (David Beckemeyer) (09/13/88)
In article <19880906162643.1.JRD@MOA.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: > Since can't run it I can't be of much immediate assistance. Does > anyone here have suggestions? My guess is the MT C shell does command > line arguments differently than gulam (the shell used by the guy who > did the port). > >Yes, I'd guess that's true, but it's still a bit mysterious how it could >get as confused as he describes. Could it be that MT upcases command >lines before executing them? > Perhaps others are interested too, so I'm posting this to help clear it up. MT C-Shell V1.10 or higher and Micro C-Shell 2.70 and higher pass arguments and environment variables using the "standard" established by Mark Williams Company's Micro Shell (msh) and compiler libraries. MT C-Shell does *not* convert the arguments to uppercase. Some C-runtime utilities (namely the one Atari shipped to developers) converts arguments to *lower* case before placing them in argv[]. The MWC argument/environment passing method is documented in their manual. If anyone is interested in the format and cannot obtain by other means, contact me and I will send you some info. -- David Beckemeyer | Beckemeyer Development Tools | "Reckon the Ball's plumb open now, 478 Santa Clara Ave, Oakland, CA 94610 | and it's `swing partner'!" UUCP: {rutgers,sun}!hoptoad!bdt!david |
jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (09/19/88)
Date: 9 Sep 88 03:34:23 GMT
From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net (Simon Poole)
In article <JEFF.88Sep2035059@stormy.atmos.washington.edu> jeff@stormy.atmos.washington.edu (Jeff Bowden) writes:
>I grabbed the gcc executables a few days ago. I found that I had
>insufficient resources to run it (sob :-( ).
Gcc can be run on a 1 MB machine! You will not be able to compile any larger
files from GULAM, but you can revert to compiling from the Desktop if memory
is a problem.
To bootstrap you NEED:
a copy of gulam
a diskeditor
1) patch the executable of gcc-cc1.ttp so that only 300 kB of stack instead
of 500 kB are allocated (you can search for the value 500000, it only
occurs once, somewhere around 364kB).
Yah, that's described in the blurb. In fact, 300000 is still far more
than you need; in my experience, 128K is plenty for most things. The
thing that really eats stack is compiling large hairy functions is -O;
the 500000 value is for compiling the instruction-cracking routing in
GAS. If you can live without -O, 64K or maybe even 32K will be enough.
[That you have to do this is really
a bug, there is NO need for a GEMDOS only program, that doesn't exec
another program to give memory back to GEMDOS, I'm changing my crt0
so that it will take -1L in _stksize to mean: "Don't do a Mshrink"]
Careful; memory that is malloc'ed comes from ABOVE the stack, not below
it, so you really do want to keep the stack at the smallest value that
works for you.
2) Now throw all resident stuff out (accessories etc. just keep GEMBOOT
or folderxxx (you do have a HD?)), start gulam and setup the enviroment
as described by jrd. You should now be able to compile most programs
(you can compile all of flex except parse.c and scan.c for an example).
This is a good time to get the sources and extract the documentation
from them, how else are you going to know about -mshort
-fomit-frame-pointer etc.?
Right. If there's sufficient demand, I'll package up the docs
separately; or someone else with more time could do so... hint hint...
3) If a source file is too large to be compiled from GULAM, you will get
a "no more virtual memory" message or someting like that (probably
already from gcc-cpp).
typically from gcc-cc1, actually...
You can workaround this by running the
compiler from the desktop, the current gcc.ttp will NOT work from the
desktop (reasons follow), so you will have to write a small wrapper
program to do this (I'm fixing gcc.ttp right now.....).
Note:
all gcc stuff assumes:
file-handle
0 = stdin
1 = stdout
2 = stderr
since the GEMDOS default for handle 2 is the serial
port, this isn't much good when you start stuff from
the desktop.
Yah, I've since realized that 2 is the serial port (!). If you fix
std-init, would you post the fixed version? Also, does anyone out there
have a description of what file numbers 'default' to what?
So you need a
Fforce(2,Fdup(1))
At the begining of your program to see any error output
(and due to a bug in stdio to see any output at all).
Trying this shows two bugs in the current runtime library:
- Fforce has a wrong binding in osbind.h,
it uses 3 short (aka 16 bit) arguments!
Write a trap-1www function to do this.
[BTW is anybody working on cleaning up
the library, there is a lot of stuff that
should be done]
No kidding. As I said in the doc, the library is pretty ragged. I'm
working on getting rid of the trap_foo functions, and generating the
traps in line; perhaps it makes sense to post a recompiled library whe
that happens?
[...]
Don't get put off by this description, GNC CC is worth it!
Glad you like it.