[9fans] cc and more

[9fans] cc and more

[Quinn Dunkan]

I'm trying to port some unix programs to plan9, and having some odd problems
with ape/cc and pcc.

: /usr/quinn/c/t; cat >test.c
main(){return(0);}
\x04: /usr/quinn/c/t; ape/cc -v -o test -lc test.c
cpp -D__STDC__=1 -D_POSIX_SOURCE= -N -I/386/include/ape -I/sys/include/ape
test.c | 8c -J -B -J -B -o libap.o 8l -o test -v /386/lib/ape/libap.a test.o
HEADER = -H0x2 -T0x1020 -D0x0 -R0x1000
inuxi = 0 01 0123
fnuxi = 0123 01234567
 0.00 ldobj: /386/lib/ape/libap.a
[ ... loader noise ... ]
??none??: cannot open file: test.o

cc: 8l: 8l 6104:error
: /usr/quinn/c/t;

/sys/src/ape/cmd/cc.c line 198 says

                    append(&cc, changeext(objs.strings[i], "o"));

I changed it to

                    append(&cc, changeext(srcs.strings[i], "o"));

and now things seem to work.  The same applies to pcc.

Also, plan9 won't run during the day.  If I run it when it is still light
outside, I quickly get random suicides, with strange results, including
filesystem corruption, and the occaisional kernel panic.  When I run it after
hours all is fine.  I'm adjusting my sleep schedule accordingly.

I can only think of heat.  It does get quite warm during the day, but linux on
the same machine never has a problem.  Perhaps plan9 uses the hardware or
memory differently that is in some obscure way more sensitive to the heat.

Also, booting plan9 with lilo works just fine, although there is a brief pause
after 'PBS...Plan 9 from Bell Labs'.

And... I'm getting corruption on certain files coming off of dos partitions.
For example, the wrap.tgz update worked fine, but the 06070617.9gz doesn't
come over as a valid gzip (works fine from linux, though).  Someone else on
the list mentioned something that sounded similar.

And I'm happily using /dev/kbdmap since I can only type in dvorak.
Thanks presotto!

Unfortunately it doesn't work with control keys so well, since you can't tell
the difference between '\010' produced by the backspace key and '\010'
produced by ^H, so when you try to map ^H to ^D where it should go, things go
wrong when you hit backspace.  Oh well.

Lastly, is there an official 9fans archive?  I found one that goes back a
little ways on mailgate.org, but maybe there's something better out there...

And really lastly, what happened to ext2srv (or whatever) used on the install
floppy?  It doesn't seem to be in the distribution...


thanks

[9fans] Official 9fans Archive

[Scott Schwartz]

> Lastly, is there an official 9fans archive?  I found one that goes back a
> little ways on mailgate.org, but maybe there's something better out there...

Since 1993, http://www.cse.psu.edu/~schwartz/9fans/archives

Re: [9fans] cc and more

[rob pike]

Quinn is right; ape/cc and pcc have a nefarious bug.  We never caught
it because it is triggered by specifying libraries explicitly, which is
almost never necessary in Plan 9 - our `autolib' #pragma figures out
which libraries to use.  But if you override that, for whatever reason,
you can overwrite the wrong files.  Quinn did
	ape/cc -v -o test -lc test.c
which caused the output to be written to /$objtype/lib/ape/libc.a.
(The -lc is unnecessary and in fact erroneous).

Here are the patches:

diff -n /n/dump/2000/0708/sys/src/cmd/pcc.c /sys/src/cmd/pcc.c
/n/dump/2000/0708/sys/src/cmd/pcc.c:154 c pcc.c:154,157
< 			append(&cc, objs.strings[i]);
---
> 			if(cflag)
> 				append(&cc, oname);
> 			else
> 				append(&cc, changeext(srcs.strings[i], ot->o));

diff -n /n/dump/2000/0708/sys/src/cmd/pcc.c /sys/src/cmd/pcc.c
/n/dump/2000/0708/sys/src/cmd/pcc.c:52 c /sys/src/cmd/pcc.c:52
< 	int i, cppn, ccn;
---
> 	int i, cppn, ccn, oflag;
/n/dump/2000/0708/sys/src/cmd/pcc.c:53 a /sys/src/cmd/pcc.c:54
> 	oflag = 0;
/n/dump/2000/0708/sys/src/cmd/pcc.c:69 a /sys/src/cmd/pcc.c:71
> 			oflag = 1;
/n/dump/2000/0708/sys/src/cmd/pcc.c:154 c /sys/src/cmd/pcc.c:156,159
< 			append(&cc, objs.strings[i]);
---
> 			if(oflag && cflag)
> 				append(&cc, oname);
> 			else
> 				append(&cc, changeext(srcs.strings[i], ot->o));

Re: [9fans] cc and more

[rsc]

  And... I'm getting corruption on certain files coming off of dos partitions.
  For example, the wrap.tgz update worked fine, but the 06070617.9gz doesn't
  come over as a valid gzip (works fine from linux, though).  Someone else on
  the list mentioned something that sounded similar.

I assume the md5sums produced by Linux and Plan 9 are different?
(It could be our gzip rather than dossrv, but that seems unlikely.)

  And really lastly, what happened to ext2srv (or whatever) used on the install
  floppy?  It doesn't seem to be in the distribution...

Ext2srv is a program I've been carrying around for a while but
isn't in the main source tree; it was a beta program a couple
years ago, is now outdated, and almost certainly some bugs
lurk in it.  I changed it for the install process to open the disk
read only mode so as not to hurt disks.  Forsyth has something
(ext2fs) on his web page that may work better.  If you type
ext2fs (or ext2srv) into google I'm sure you'll come up with it.

Russ