culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (08/14/90)
Jyrki writes: > Oh yes, I shuld warn you: when using the gcc 1.35 which comes with > the Bruce's port, GNU make and fileutils didn't work. I suspected the > libraries or the old version of gcc; then I got gcc 1.37.92 working > and tried again and both make and fileutils worked just fine. So > before spending that much time on debugging, you should get a new > version of gcc. I do not want people to get the impression that I am sending out an unreliable compiler. I have compiled an enormous amount of code with it and it has worked exquisitely. It has only one bug which I have seen -- and 1.37 has the same bug. 1.37 has virtually the same backend. I am certainly not opposed to upgrading but have given it a low priority because 1.35 has proved to be so reliable. Perhaps Jyrki could provide some more specific information. > ...we're having trouble with minix's arg list limitations; often we > get 'exec: Arg list too long') Pc532 Minix, as distributed, has this problem 90% fixed. That is, 90% of the work done, 0% of the benefit realized. Sigh. MS-DOS Minix relocates the environment in a fixed size buffer in the OS, making the limitation hard to fix. Pc532-Minix OS code will copy an arbitrary size environment -- the only limitation is in the library routine exec.c. Exec.c assembles the environment into a contiguous block. It does this in a fixed size buffer (and should continue to do so to avoid a break system call in the usual case). This usually succeeds (I have never had it fail but I am not using GNU make). New code is needed, however, to handle the case where the buffer is not big enough. When this happens, a break call should be made to allocate a considerably larger buffer. Anyone want to fix this and post a new routine for the rest of us? By the way, I am now using the 1.5.10 version of FS. Here are some benchmarks. 1.3 FS 1.5 FS Benchmark --------------------------------------------------------- 8.0 8.0 cp /lib/cc1 /dev/null 37.0 17.0 cp /lib/cc1 /tmp/tmp Compiles are noticeably faster with this new version. I am using a very funky old disk so others may get better results. John Connen has also made considerable progress with 1.5. The entire 1.5 system may be ready to distribute in a month. That's a crude guess. Regards, Bruce Culbertson
jkp@cs.HUT.FI (Jyrki Kuoppala) (08/17/90)
In article <9008131835.AA06211@hplwbc.hpl.hp.com>, culberts@hplwbc (Bruce Culbertson) writes: >Jyrki writes: [ the distrib gcc 1.35 not working with GNU make and fileutils ] >I do not want people to get the impression that I am sending out >an unreliable compiler. I have compiled an enormous amount of code >with it and it has worked exquisitely. It has only one bug which I >have seen -- and 1.37 has the same bug. 1.37 has virtually the same >backend. I am certainly not opposed to upgrading but have given it >a low priority because 1.35 has proved to be so reliable. Perhaps >Jyrki could provide some more specific information. There are a few changes in the md file at least between 1.37 and 1.37.92 which we're using. I haven't looked at them closely, so I don't remember what they are. I tried to compile GNU make again with the distrib cc (gcc 1.35), and now it seems to work fine with and without -O. Strange, perhaps it was a problem with our environment back then. But GNU ls still fails - it only outputs the first file with ls -l when compiled with cc -O. Works fine with gcc 1.37.92. I don't think I'll dig into the problem deeper as it works with the newer gcc. If you install a newer version, you of course have always the option to use the old version (we have Bruce's gcc 1.35 as cc, 1.37.92 as gcc). As Bruce says, the old one is probably not that bad either. >block. It does this in a fixed size buffer (and should continue to do >so to avoid a break system call in the usual case). This usually >succeeds (I have never had it fail but I am not using GNU make). Yes, I think GNU make puts all make variables into the environment so it tends to make the env a little big huge sometimes ;-) I placed the diffs for gcc 1.37.92 (well not quite, it's snarfed from MIT sometime before 1.37.92 test release) in nic.funet.fi, directory pub/misc/pc-532/GNU-hut. The diffs should work for 1.37.1 as well as the test release it is for, but I haven't checked - line numbers may vary. The diff is not quite clean / finished yet, so distributing it very widely might not be that a good idea. //Jyrki
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (09/05/90)
Hi gang,
I am delighted to see so much recent pc532 activity. Several people are
pounding on Minix in ways I haven't and are consequently seeing weird
behavior I haven't experienced. Keep it up -- eventually this will
result in a better OS.
Several people have reported that the passwd command is broken. You're
right. I set my password and then I updated the standard IO library.
Since I didn't need to change my password, I didn't notice that the new
library broke passwd.
Passwd uses a light-weight printf called prints. Prints does not do a
flush after each call, which is why you do not see the passwd prompts.
Worse, the prompts can wind up in your /etc/passwd file, making login's
impossible. Passwd uses the cute trick of close'ing (not fclose'ing)
stdout and then opening /etc/passwd as stdout. When the flush finally
occurs, the prompts go into /etc/passwd.
Do not try to fix this by putting something like
#define prints printf
into passwd.c. Because the library routine getpass calls prints,
passwd will still fail with this fix.
Instead put this at the end of passwd.c and recompile:
prints (f, a, b, c)
char *f, *a, *b, *c;
{printf (f, a, b, c);}
That will probably get the portability police on my back -- use VARARGS
if you prefer. Next, I will criticize other people's poor quality code.
Several people have reported that code like this will not work:
foo()
{
char bar[] = "Hello";
strcpy (bar, "Bye");
}
This has never been legal C, although it worked on some computers.
(Well, maybe K&R were vague on the subject, but it sure is illegal now.)
GCC puts the string "Hello" into the text segment, which is write
protected in my Minix implementation. Hence, the strcpy() gets a bus
error when it tries to write it. Since there is some of this kind of
code still around, GCC provides a "-fwritable-strings" option to put the
"constant" strings into the data segment.
Have fun,
Bruceculberts@hpccc.HP.COM (Bruce Culbertson) (09/07/90)
Oops! I goofed.
In my note titled "Minix comments", change
foo()
{
char bar[] = "Hello";
strcpy (bar, "Bye");
}
to
foo()
{
char *bar = "Hello";
strcpy (bar, "Bye");
}
-- Bruce