robtu@itx.isc.com (Rob Tulloh) (03/21/91)
I am resubmitting this post again in hopes that maybe I didn't post
it correctly the first time. Help!
--------------------
I recently pulled GCC from abcfd20.larc.nasa.gov and began playing around
with it on my Amiga 500. So far, I really like it a lot better than other C
compilers I have tried (although I do admit to only using the free/shareware
variety) for the Amiga.
I have encountered a problem that I need help with. I pulled the popen.lzh
archive from abcfd20.larc.nasa.gov and tried to compile and run it on
my system. In order to use it, I had to be able to access the ASyncRun()
subroutine in the ARP library. I pulled the ARP library sources from the
net and used the Bind program to convert arp_lib.fd into a library suitable
for linking with (the Bind program is something that came with the PDC
release I was using before I got gcc). The library seemed to build just
fine (I used a68k and zlib to build it) and gcc links with it just fine.
Now, the problem. I am able to run the test program that comes with the
popen source code, and in the case that I read pipes - no problem. Writing
to a pipe causes a [0]+00003 guru message every time. I sent e-mail to the
author and got some hints on things to try (thanks Rick!), but nothing
seems to work. I tried changing the pipe: device to be the ip: device
since I heard there were problems with the native pipe:. I tried recompiling
the code using PDC and get the same result. I am running WB 1.3 (v. 34.28)
and I have 3 megs of memory installed (so I don't think it is a memory
problem). I saw the thread posted about possible problems with ARP and
was wondering if my problem is perhaps related to this. Anyone else
out there tried to use these routines? Am I having ARP problems?
----------------
Update! I have determined that specifying pcb_Output in the PCB struct
can make a difference. The docs indicate that not setting this field
will force ASyncRun() to inherit the current CLI's window for output.
Not so (or so it seems)! I tried setting the handle to something known
like Open("ram:foo",MODE_NEWFILE) and it works like a champ. This also
works when you Open() things like NIL: and pipe:foo too. Now, if I
hand it the result of Output() explicitly, it still bombs. I tried
pulling the pr_COS handle from the Task struct and it bombs, I dug one of
the output handles from the cli struct and it bombs. I tried to open
the current window again - Open("*",mumble mode) - and it still bombs!!!
Also, if I set the pcb_Control flag to PRF_STDIO, ASyncRun will open
a second window and then hang both the current window and the new window.
Not the same as the guru, but equally useless since I still have to
reboot the machine.
I am perplexed as to why I can't write to standard output. Buffering
the output or throwing it away is not as desirable as seeing it first
hand. Has anyone else running an A500 and WB1.3 seen this behavior?
Any help would be greatly appreciated!
Rob Tulloh
--
INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116
9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!)
Arboretum Plaza One, Suite 700 Net: robtu@itx.isc.com (polled daily)
Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)
--
INTERACTIVE Systems Corp. Tel: (512) 343 0376 Ext. 116
9442 Capital of Texas Hwy. North Fax: (512) 343 0376 Ext. 161 (not a typo!)
Arboretum Plaza One, Suite 700 Net: robtu@itx.isc.com (polled daily)
Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)