| From: | Aaron Optimizer Digulla |
| Date: | 1 Aug 2000 at 17:54:46 |
| Subject: | AMIOPEN: Another problem with compiling ixemulng |
Well, suddenly and quite unexpected, the error "`va_start' used in tool
function with no varargs attribute" went away for the file ixemul_exec
(but not for execl*.c !?). I wonder what's going on :-/ Anyway,
I fixed all typos and bugs and implemented the missing path
functions but now I'm stuck again (too blind to see the error,
as usual).
Here is what I see when I run "make check":
Amiga 1.0:/packages/ixemulng$ make check
and {cd tests} {make}
make[1]: Entering directory `/packages/ixemulng/tests'
vpcc -Wall -g -I../include -DTEST -o tjoinpath ../joinpath.c
./tjoinpath
All tests OK.
vpcc -Wall -g -I../include -DTEST -o tsplitunixsearchpath ../splitunixsearchpath
.c
./tsplitunixsearchpath
splitUnixSearchPath (".::/app:/app/stdio")
ixemulng-splitUnixSearchPath
unixSearchPath=".::/app:/app/stdio"
Need 5 entries
result[0]="."
result[1]=""
result[2]="/app"
result[3]="/app/stdio"
result=$40813960
result=$40813960 ".::/app:/app/stdio"
vpcc -Wall -g -I../include -o texec texec.c
./texec
Create pipes
Calling splitUnixSearchPath...
Done with splitUnixSearchPath
searchPath=$412d4220
make[1]: *** [texec] Error 7
make[1]: Leaving directory `/packages/ixemulng/tests'
make: *** [check] Error 2
Amiga 1.0:/packages/ixemulng$
The interesting part are below "./tsplitunixsearchpath". This is
a test for the splitUnixSearchPath() code. As you can see, the
code will print some infos (that it has been called in
"ixemulng-splitUnixSearchPath" and the argument
(unixSearchPath=".::/app:/app/stdio")). Then it
prints the split-up path. Nice. The test for the result looks
OK, too (result=$40813960 ".::/app:/app/stdio").
Then texec is compiled. It also calls splitUnixSearchPath()
between (Calling ... and Done...) but this time, there is no
output by the routine !! Instead, I just a pointer back
which probably points to invalid memory.
Also I'm unsure what this "*** [texec] Error 7" means.
There is no exit in the code at this point :-/ I would
expect a segfault but that doesn't happen.
Also, I noticed a tendency of Ami to become unstable
when I run this test more often and when I compile it
several times. Ami didn't crash but the texec binary
fails earlier and with all kinds of strange outputs.