Hi,<div><br></div><div>I just encountered a peculiarity with the perform method for elephant-c-source files, which causes a clean build of elephant-unstable on Windows/SBCL fails with the following<br clear="all"><br></div>
<div><div>; $ gcc -mno-cygwin -mwindows -Wall -c -std=c99 "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.c"</div><div>; $ dlltool -z "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.def" --export-all-symbols -e exports.o -l "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.lib" "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.o"</div>
<div>dlltool: Unable to open object file: C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.o</div>
</div><div><br></div><div>The first command assume the working directory is "C:\Program Files\asdf\elephant-unstable\src\memutil\", which is done in ACL and Lispworks by explicitly specifying a directory option with the run command. But SBCL, and run-shell-command specifically, seem to have no option for doing this. So the files end up in some unknown place (which most definitely isn't the memutil directory).</div>
<div><br></div><div>I tried specifying the output files explicitly, which almost works, except dlltool blows up when receiving a path with a space in it, even when it is in quotes.</div><div><br></div><div><div>; $ gcc -mno-cygwin -mwindows -Wall -c -std=c99 "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.c" -o "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.o"</div>
<div>; $ dlltool -z "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.def" --export-all-symbols -e "C:\Program Files\asdf\elephant-unstable\src\memutil\exports.o" -l "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.lib" "C:\Program Files\asdf\elephant-unstable\src\memutil\libmemutil.o"</div>
<div>Assembler messages:</div><div>Error: can't open Files\asdf\elephant-unstable\src\memutil\exports.o for reading: No such file or directory</div><div>dlltool: as exited with status 1</div><div><br></div></div><div>
So the attached patch fixes Windows/SBCL building the dlls from c source, when the directory name contains no spaces. I would NOT suggest applying it to the main repository, but I would like to get comments on how to fix this problem, if any.</div>
<div><br></div><div>Thanks. Any suggestions would be appreciated.</div><div><br></div><div>P.S. I'm also curious why Windows requires 3 commands to build a dll in the first place, whereas Linux uses only one.</div><div>
<br>-- <br>Elliott Slaughter<br><br>"Any road followed precisely to its end leads precisely nowhere." - Frank Herbert<br>
</div>