david@doe.utoronto.ca (David Megginson) (10/24/90)
I have noticed a query about using gcc under RTX (MT C-Shell).
I posted this message a couple of weeks ago, but here it is
again (slightly modified at the end):
(cut here)
====================================================================
A few days ago, I posted my suspicion that it was the freopen()
function which keeps gcc-cpp.ttp from running with MT C-Shell
(under Micro RTX). I still have not seen the gcc-cpp.ttp source,
but I did try out this test program:
#include <stdio.h>
main()
{
FILE * fp;
fp = freopen("hack.txt","w",stdout);
if( fp )
fclose(fp);
else
fprintf(stderr,"Cannot open hack.txt\n");
}
The program runs under TOS and MiNT, but not under RTX (which prints the
error message). The reason is that the Gnu freopen() function in this case
attempts to close the standard handle associated with stdout, which
(correctly) causes an error under RTX, while TOS and MiNT are a little
more lenient.
NOTE: compress.ttp also suffers from this problem (the one from
atari.archive in atari/gnustuff/tos).
PATCH:
Here is a little patch for the close() function in a compiled GCC 1.37
program. Note that this may not work for you, and may even cause the
program to malfunction! Use with care, and back up your originals. What
the patch does is simply have close() return no error even when there is
one.
Search for the following bytes with your binary editor:
3f 3c 00 3e 4e 41 58 4f 34 00 48 c2 6c 0a
|
74
Change the byte indicated from 34 to 74 (make sure that the _entire_ string
is correct first). Instead of copying the return value from Fclose() from
a0 to a2, this patch has the function set a2 to 0 (success) in all
circumstances.
SUCCESS:
compress.ttp does not complain about errors opening files when this patch
is applied, but I have not tested it past there.
gcc works, but it needs a little more help. You will have to set the
tpa to a higher value before you run it (see the shareware RTX
release for details on how to do this). I set it to 512K and gcc
seems to run fine, at least with smaller programs. With larger
programs or hyper-optimised ones, you may need to set the tpa
to 1024K or greater (the default in MT C-Shell is 64K). Remember,
gcc needs A LOT OF MEMORY. Give up on running it under MT C-Shell
(or, probably, MiNT) on a 1 meg machine. The Sozobon package is
rather simplistic, but it will run nicely in a smaller memory space
(it does not work as-is under RTX, though, because of a nasty
DLibs bug!!!).
David Megginson
--
////////////////////////////////////////////////////////////////////////
/ David Megginson david@doe.utoronto.ca /
/ Centre for Medieval Studies meggin@vm.epas.utoronto.ca /
////////////////////////////////////////////////////////////////////////7103_2622@uwovax.uwo.ca (Eric Smith) (10/27/90)
In article <1990Oct24.164834.21929@doe.utoronto.ca>, david@doe.utoronto.ca (David Megginson) writes: > > The program runs under TOS and MiNT, but not under RTX (which prints the > error message). The reason is that the Gnu freopen() function in this case > attempts to close the standard handle associated with stdout, which > (correctly) causes an error under RTX, while TOS and MiNT are a little > more lenient. > "Correctly?" I can recall no TOS documents that forbid closing handle 0. Since TOS does permit it, I would conclude that closing stdout should cause no error. Note that Unix works the same way. -- Eric R. Smith email: Dept. of Mathematics ersmith@uwovax.uwo.ca University of Western Ontario ersmith@uwovax.bitnet London, Ont. Canada N6A 5B7 ph: (519) 661-3638