gjh@hplb.hpl.hp.com (Graham Higgins) (02/11/91)
Cliff Stein writes:
++ I'm using G++ 1.35 and GCC 1.36.
++ BTW: Are there any newer versions of these?
GCC versions have reached 1.39 on terminator, but only 1.37.1 appears in binary
form (1.38 and 1.39 are in "diff" form).
What I'm concerned about is that the GCC-using ST community is dependent on
*someone else* doing the cross-compilation to get these diffs into binary
format. (Or are they --- has anyone got a GCC v1.39 executable by compiling it
up on an ST?)
For a brief period last year, we lost our primary supplier (Hi jbammi!), what
happens if it's permanent next time? (He might swap his ST for a TT [or best
offer] and then where are we?)
I have tried to follow a path designed to produce an ST GCC-bootstrap
distribution (get the compiler to compile its own sources, and work through the
libs, gdb, binutils, etc) but I find that it's *extremely* difficult to
a) collate everything required --- it's a dynamic list!
b) integrate the various gcc, gas & ld options.
c) track down the various library sources (e.g. termcap)
I tried to compile gcc v139 but bison fell over a .y file --- now I have to
find out whether GCC 1.37 and byacc are still in synch. These problems
generally don't appear when cross-compiling on Eunuchs boxes for example ---
but they do tend to arrive in hordes when ST-bootstrapping.
Cheers,
Graham
======
------------------------------------------------------------------
Graham Higgins | Phone: (0272) 799910 x 24060
Hewlett-Packard Labs | gjh%ghiggins@hpl.hp.co.uk
Bristol | gjh%ghiggins@hplb.hpl.hp.com
U.K. |
------------------------------------------------------------------
Disclaimer: My opinions above are exactly that, mine and opinions.
------------------------------------------------------------------bjsjr@NCoast.ORG (Bill Shroka) (02/18/91)
In article <GJH.91Feb11103129@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: > >GCC versions have reached 1.39 on terminator,but only 1.37.1 appears in binary >form (1.38 and 1.39 are in "diff" form). > >What I'm concerned about is that the GCC-using ST community is dependent on >*someone else* doing the cross-compilation to get these diffs into binary >format. (Or are they --- has anyone got a GCC v1.39 executable by compiling it >up on an ST?) I've compiled GCC 1.39 on my ST. I used the GULMAKE package that was created by Jim Hurley. It's a series of Gulam scripts that automates the make process. It takes about 2 or 3 hours to completely compile GCC and I experienced relatively few problems, though it's something I'd rather not do very often :-) -- -------------------------------------------------------------------------- Bill Shroka bjsjr@NCoast.ORG ncoast!bjsjr@usenet.INS.CWRU.Edu
jimh@ultra.com (Jim Hurley) (02/22/91)
In <1991Feb17.234055.25173@NCoast.ORG> bjsjr@NCoast.ORG (Bill Shroka) writes: >In article <GJH.91Feb11103129@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes: >> >>GCC versions have reached 1.39 on terminator,but only 1.37.1 appears in binary >>form (1.38 and 1.39 are in "diff" form). >> >>What I'm concerned about is that the GCC-using ST community is dependent on >>*someone else* doing the cross-compilation to get these diffs into binary >>format. (Or are they --- has anyone got a GCC v1.39 executable by compiling it >>up on an ST?) >I've compiled GCC 1.39 on my ST. I used the GULMAKE package that was created >by Jim Hurley. It's a series of Gulam scripts that automates the make process. >It takes about 2 or 3 hours to completely compile GCC and I experienced >relatively few problems, though it's something I'd rather not do very often :-) >-- >-------------------------------------------------------------------------- >Bill Shroka >bjsjr@NCoast.ORG >ncoast!bjsjr@usenet.INS.CWRU.Edu As Bill says, this is a tedious process on the ST, but it is doable. The only problems I have ever encountered were occasional 'make' errors, or maybe gulam-make interaction errors. However, re-executing the 'make' picked up right where it left off. So far, I haven't had any problems compiling or porting the GNU software, (with the exception of 'less'), but you will probably need 4Mbytes and a 32Meg HD partition (to store all the source in one directory). Thanks to J. Bammi, et al, and their excellent gnulibs. Another error comes to mind now - the version 1.37 'ar' aborts when it tries to rename the final library archive, but it was built OK and you can manually rename it. This was fixed in a later release of the package. In the 'gulmake' package I listed the complete directory structure I used, to make things as fool-proof as possible. Don't forget to start with the 'zoo' from Bammi's package first! Otherwise you need to be careful to replace filename '_' with '-' unpacked from older 'zoo' programs. A question comes to mind - the GNU 'tar' program seems to have extremely small block sizes built into it, at least this is how I explain the chain-saw-like buzzing off my hard disk while unpacking files. I've never heard that sort of seek noise from any other program. Does anyone know what's happening here? I haven't looked at the source. -- Jim Hurley --> jimh@ultra.com ...!ames!ultra!jimh (408) 922-0100 Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
erlingh@idt.unit.no (Erling Henanger) (02/22/91)
OK, so it's possible to compile GCC/G++ on the ST if you have the time (:-)
But is it also possible to compile EMACS ?
And/Or has anyone made an attempt to get emacs running under mint, taking
advantage of this new environment ? If not, and if it is possible to compile it on my ST, I'll have to do it myself I guess... I really hate that I can't press CTRL-G in emacs (under MGR), and I also hate the cursor blinking on the desktop under MGR/emacs.
--
_______ _____ o ____ Erling Henanger
/___ /____/ / / /| / / Norwegian Institute
/ /\ / / / | / | ___ of Technology. (NTH)
------ / \ /____ / / |/ \____| o Atari Lives !bammi@acae127.cadence.com (Jwahar R. Bammi) (02/23/91)
In article <1991Feb21.181331.784@ultra.com> jimh@ultra.com (Jim Hurley) writes: > A question comes to mind - the GNU 'tar' program seems to have extremely > small block sizes built into it, at least this is how I explain the > chain-saw-like buzzing off my hard disk while unpacking files. I've i guess others will be interested too, so i am posting instead of mailing. the makefile defines DEFBLOCKING == 2, so things are done with blocksize = 2 * 512. you can change this by using the 'b' (set blocking factor) command line option, or by recompiling with a large DEFBLOCKING. -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155
7103_2622@uwovax.uwo.ca (Eric Smith) (02/25/91)
> OK, so it's possible to compile GCC/G++ on the ST if you have the time (:-) > But is it also possible to compile EMACS ? Yes. > And/Or has anyone made an attempt to get emacs running under mint, taking > advantage of this new environment ? Someone wrote to me a while back and said he had done this -- he also said it was very easy to do with the MiNT library (although he didn't define "very easy" :-). I forget his name, though -- if you see this message and you have a version of emacs that works under MiNT, please send it to atari.archive! -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet
gjh@hplb.hpl.hp.com (Graham Higgins) (02/26/91)
++ I really hate that I can't press CTRL-G in emacs (under MGR),
This bit me for a while until I tracked it down --- it is a "feature" of
'vt52.prg'. ^G is defined as an abort character, which causes it to drop out
the whole caboodle. Try recompiling vt52.c in your mgr sources, assigning a
different character to the abort. I am successfully using 'me.tos' inside an
mgr window with something like the following (ksh) function ...
function ved()
{
vt52 me.tos ${1}
echo '\014'
}
Question --- has anyone succeeded in getting mgr to recognise any of the ST
cursor keys, or the HELP/UNDO keys?
I have another question. With a machete, I rejigged 'zmdm' to run under mgr
(removing the screen memory calls and anything else I thought might interfere
with mgr), and it works, but whilst it is connected to the RS232 port,
mgr/mint/kshv4 (something, somewhere in that trio) prevents me both from
opening other windows (can't get a pty) and from doing anything in another
already-existing window (cannot fork, try later). Could anyone hazard a guess
as to whether it's something I did to the zmdm code, or whether there's
something else that's biting me.
I redid the whole thing as an mgr application, using mgr library calls, but I
suspect that m_setup() remaps the ports 'cos I can't get any characters out of
the rs232 port, I wonder if Bconstat(rs232) is actually checking the rs232
port? Bconstat(console) seems to work OK.
Graham
======
------------------------------------------------------------------
Graham Higgins | Phone: (0272) 799910 x 24060
Hewlett-Packard Labs | gjh%ghiggins@hpl.hp.co.uk
Bristol | gjh%ghiggins@hplb.hpl.hp.com
U.K. |
------------------------------------------------------------------
Disclaimer: My opinions above are exactly that, mine and opinions.
------------------------------------------------------------------entropy@ai.mit.edu (entropy) (02/27/91)
In article <GJH.91Feb26102918@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com (Graham Higgins) writes:
I have another question. With a machete, I rejigged 'zmdm' to run under mgr
(removing the screen memory calls and anything else I thought might interfere
with mgr), and it works, but whilst it is connected to the RS232 port,
mgr/mint/kshv4 (something, somewhere in that trio) prevents me both from
opening other windows (can't get a pty) and from doing anything in another
already-existing window (cannot fork, try later). Could anyone hazard a guess
as to whether it's something I did to the zmdm code, or whether there's
something else that's biting me.
The problem is zmdm is taking up all of memory. Use the 'limit'
program distributed with MiNT and it should work OK. For example:
limit -m 512k zmdm.ttp
By the way, has anyone noticed that certain programs (such as the CPM
emulator) completely ignore 'limit' and snarf all of memory anyway?
entropy7103_2622@uwovax.uwo.ca (Eric Smith) (03/01/91)
In article <ENTROPY.91Feb26154539@wookumz.ai.mit.edu>, entropy@ai.mit.edu (entropy) writes: > > By the way, has anyone noticed that certain programs (such as the CPM > emulator) completely ignore 'limit' and snarf all of memory anyway? > There are two different flags for limiting memory: -M and -m. One of them (I forget which) limits the amount of memory the process can Malloc; the other limits the total amount of memory the process can have. Some programs never use Malloc or Mshrink; they just keep all the memory they're given on startup -- for them, you have to use the latter flag. -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet
entropy@ai.mit.edu (entropy) (03/01/91)
In article <1991Feb28.133252.8714@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: In article <ENTROPY.91Feb26154539@wookumz.ai.mit.edu>, entropy@ai.mit.edu (entropy) writes: > By the way, has anyone noticed that certain programs (such as the CPM > emulator) completely ignore 'limit' and snarf all of memory anyway? There are two different flags for limiting memory: -M and -m. One of them (I forget which) limits the amount of memory the process can Malloc; the other limits the total amount of memory the process can have. Some programs never use Malloc or Mshrink; they just keep all the memory they're given on startup -- for them, you have to use the latter flag. Please, Eric, give me some credit (I do know how to RTFM if nothing else). I've tried both flags independently and in conjunction and neither has any effect on the CP/M emulator. I could swear I noticed another program that acted similarly but I can't for the life of me think of what it was right now. In any case, I seriously doubt this indicates a problem with limit. It's probably just that the emulator does something really stupid (and likely illegal) to allocate its memory. If anyone's had any better luck getting the emulator to use less memory, please let me know. entropy
7103_2622@uwovax.uwo.ca (Eric Smith) (03/02/91)
In article <ENTROPY.91Mar1022109@wookumz.ai.mit.edu>, entropy@ai.mit.edu (entropy) writes: > In article <1991Feb28.133252.8714@uwovax.uwo.ca> 7103_2622@uwovax.uwo.ca (Eric Smith) writes: > There are two different flags for limiting memory: -M and -m. One of > them (I forget which) limits the amount of memory the process can Malloc; > the other limits the total amount of memory the process can have. > Some programs never use Malloc or Mshrink; they just keep all the memory > they're given on startup -- for them, you have to use the latter flag. > > Please, Eric, give me some credit (I do know how to RTFM if nothing > else). I've tried both flags independently and in conjunction and > neither has any effect on the CP/M emulator. No offence intended -- lots of people (myself included) sometimes overlook things in the FM even when they read it. I'm puzzled that the CP/M emulator ignores limit; does it otherwise work OK under MiNT (i.e. can you run it in the background and not have it interfering with other programs)? It's quite possible that, as you suggest, it simply uses all of memory without going through the OS; but in that case it probably will trash any other programs running at the time. Alternatively, there very well could be a bug in MiNT. (heaven forbid :-). -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet