Compiler detection doesn't seem to work on Windows with version 2.1.0 binaries

[dnm]

Compiler detection, either autodetection with a should-be-valid compiler in %PATH%, or a specified path to a compiler (via using the Browse button in the Editor Settings dialog), doesn't seem to work on Windows with the 2.1.0 binary release.

I can confirm I'm using the compiler binaries from https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2020.04.1-x86_64-w64-mingw32.zip via https://github.com/sifive/freedom-tools/releases. Looking at the test program embedded in ccmanager.cpp ("int main() { return 0; }"), I can successfully compile this with the following command line ("risc-foo.c" contains only the string above as the entire program):

riscv64-unknown-elf-gcc -march=rv32im -mabi=ilp32 -O0 -x c risc-foo.c -o risc-foo -static-libgcc -lm

I can also load the resulting (ELF) binary into Ripes (via Ctrl+O or "Load Program" under the File menu) and run it in the simulator.

Similarly, I tried a more complex sample, as shown at https://github.com/mortbopet/Ripes/wiki/Building-and-Executing-C-programs-with-Ripes:

#include <stdio.h>

int main() {
   char buffer[128];
   printf("Type something to be echoed:\n");
   fflush(stdout);
   fgets(buffer, sizeof(buffer), stdin);
   printf("\nYou typed: %s", buffer);
   return 0;
}

This also compiles fine with the following command line, and likewise the binary loads fine in Ripes ("risc-foo2.c" is only the program source shown above):

riscv64-unknown-elf-gcc -march=rv32im -mabi=ilp32 -O0 -x c risc-foo2.c -o risc-foo2 -static-libgcc -lm

I'm uncertain what exactly is failing (or seems to be failing) on Windows with the 2.1.0 release binary WRT compiler detection.

[mortbopet]

Thank you for the elaborated explanation of the problem. Just to make sure - when manually browsing to the compiler executable, are you also specifying the .exe suffix?

This is why the automatic compiler detection is not working on windows - it currently does not consider any suffix for the expected compiler executable (this should obviously be fixed in the code).

edit: Sorry, the .exe should not be a requirement for the execution of the compiler. I will just have a go myself with the specific toolchain version which you specified.

[mortbopet]

I am not able to reproduce the issue on my windows machine (see below). Have you by any chance modified the default compiler and linker arguments? I would also not rule out that there is something wrong going on within Ripes, most likely in CCManager::compile. It's been (surprisingly) tricky to get the asynchronous execution of the compiler right. And while i managed to get it working on all three targeted platforms during my testing, i unfortunately do not have full confidence in it.

[dnm]

I can't be 100% certain, but I'm pretty sure I haven't modified the default compiler arguments nor the linker arguments in the dialog.

Interestingly, I've never successfully seen a sample "Compile command" displayed in this dialog.

Here's my current settings (with a manually specified compiler executable picked via the Browse button)

[mortbopet]

Those settings looks good to me, so this must mean that there in fact is something going wrong inside Ripes when trying to validate the compiler.

I've made a debug build available here: https://github.com/mortbopet/Ripes/releases/download/continuous-prerelease/Ripes-prerelease-win-x86_64.zip Using Windows DebugView you should be able to capture the debug output messages - On failed compiler verification, any output from the compiler will be dumped as debug output which (hopefully) should help us in narrowing in on the issue.

[dnm]

Hrm. I downloaded the debug build, but for some reason it won't run on my machine. Or doesn't seem to anyway. No error message (and nothing in DebugView), just returns quickly after invocation from a Command Prompt or just nothing if Ripes.exe is double-clicked. At first I thought I may need to wait a while (since it's a debug build), but the process doesn't show up in the process tree so it seems to be exiting quickly on launch for some reason.

[mortbopet]

Even more strange! i tested the debug build on my windows machine and it was able to execute the binary.

Hmm... Do you have a Qt environment set up for building Ripes?

[dnm]

Sorry, I didn't have time to dig into this further until a little while ago.

I think the reason the debug build doesn't work for me is it's linked against the debug versions of the runtime libraries, i.e. VCRUNTIME140D.dll, MSVCP140D.dll, ucrtbased.dll. While the Qt debug libraries were included in the archive, these are not.

Regarding a Qt build environment, I don't have one set up, at least at present. I could go down that road, but at the risk of perhaps being a bit silly, do you mind if I try to investigate some other angles first? Would it be possible to get a debug build with the debug runtime libraries packaged in it? Barring that, are there useful things I could check with the release build I have?

For instance, from a quick glance at ccmanager.cpp (e.g. https://github.com/mortbopet/Ripes/blob/master/src/ccmanager.cpp#L79), I notice I should see a temporary C file (created by QTemporaryFile) starting with "Ripes" and ending in ".c" (with the middle part of the file name being unique per the behavior of QTemporaryFile acting on the template string). I can confirm that with the 2.1.0 release build executable I can see such a temporary file being created, e.g. "Ripes.ILHuFf.c" (in one particular run/launch of Ripes). I can also confirm (with the same release build) that I see Ripes trying to access the temporary output file "Ripes.temp.out" (https://github.com/mortbopet/Ripes/blob/master/src/ccmanager.cpp#L97), however this seems like it may not be present when Ripes attempts to e.g. perform a CreateFile operation on it in my case.

Below is a (lightly-edited) snapshot of a Process Monitor capture, filtered to show the contents described above.

[mortbopet]

Without having much knowledge of the underlying windows-API calls for file creation, i would assume that the "Delete" attribute within the CreateFile operations for Ripes.temp.out correctly reflects that at https://github.com/mortbopet/Ripes/blob/master/src/ccmanager.cpp#L97 any previously existing version of said file is attempted to be removed if it exists.

Attached are the requested runtime libraries: runtimes.zip. Assuming these do not further link to any other debug libraries, the application should execute with these unzipped within the Ripes base directory.

[dnm]

Ah hah! This found the problem straight away.

The debug version works with the contents of the runtimes.zip package, thanks for that.

The issue seems to be spaces in full pathname arguments to the compiler, which are not quoted. This could happen, for example, if your Windows user name is space-separated, e.g. "John Doe" (slightly sanitized DebugView output shown below):

[16380] Failed to compile test program
[16380] CC output: 
[16380] Standard output:  ""
[16380] Standard error:  "riscv64-unknown-elf-gcc.exe: error: C:/Users/John: No such file or directory\nriscv64-unknown-elf-gcc.exe: error: Doe/AppData/Local/Temp/Ripes.BERNrq.c: No such file or directory\nriscv64-unknown-elf-gcc.exe: error: Doe/AppData/Local/Temp\\Ripes.temp.out: No such file or directory\n"

[mortbopet]

Great! I'll push a fix as soon as possible and reference this issue.

[mortbopet]

A build which includes the fix is available at: https://github.com/mortbopet/Ripes/releases/tag/continuous-master

[dnm]

I can confirm this build fixes this issue for me! (at least in a brief test):

Thanks very much!

[dat080399]

please tell me, how to fix this issue. I meet this issue, too

[dat080399]

[mortbopet]

@dat080399 Try downloading the latest continuous release and see if the issue persists.