elena64-cli and w64devkit

[ghost]

sh: C:/w64devkit/home/elena-lang-x64-nightly-6.7.2/bin/elena64-cli.exe: Error 0xfffffffe

It seems this issue is not yet solved. @skeeto has pointed out what is causing it. I remember that @aakov has modified the code. But for unknown reasons, it's still there, in the latest nightly build for Windows 64 bit.

The old threads I posted on both the w64devkit repo and this repo are now censored from the public.

[arakov]

Could you please describe the situation once again?

And I need to know your compiler version and the platform (do you use mingw?)

It will save a lot of time if you post your compilation output.

The result -2 means that the compilation was successful but there were warnings. So the code was compiled.

[ghost]

Try running elena64-cli on w64devkit. Windows 64 bit. Even running elena64-cli without parameters, it still prints:

sh: C:/w64devkit/home/elena-lang-x64-nightly-6.7.2/bin/elena64-cli.exe: Error 0xfffffffe

[arakov]

If the compiler returns -1 (0xffffffff) - it means there is a compilation error.

If the result is -2 (0xfffffff2) - warning (but the output was generated).

In your case, it was because you do not provide the file / project to compile.

If you don't like to have compilation warnings, you can compile with the following option

elena64-cli -w0 <your project / file>

but the linker warning would be still returned

It looks like everything works as expected. The compiler returns that there were warnings during the compilation and
sh reports this error.

So what exactly I have to fix? Probably w64devkit don't like negative result code, theoretically I can return positive one.

Otherwise try it with very simple program (for example from my samples) and let me know if it works.

I'm still have no clue what you are trying to do. Please give me some context

[skeeto]

are now censored from the public

That's because YOU deleted them (as @groggily). The original report was here: skeeto/w64devkit#241 You're on thin ice, a hair's breadth away from me blocking you forever, @faded-showplace715. Because I've experienced this GitHub incompetence in the past, I maintain my own archive of of GitHub threads, so fortunately it was saved. The important bits:

Summary: It's fine, and that result normal on all platforms, including MSYS2. It's just quieter about non-zero exit statuses, so you've never noticed. [...] The busybox-w32 shell prints this message for any negative exit status. Observe: $ echo 'int main() { return 1; }' | cc -xc - && ./a $ echo 'int main() { return -1; }' | cc -xc - && ./a sh: ./a.exe: Error 0xffffffff $ echo 'int main() { return -2; }' | cc -xc - && ./a sh: ./a.exe: Error 0xfffffffe $ echo 'int main() { __builtin_trap(); }' | cc -xc - && ./a sh: ./a.exe: Error 0xc000001d On unix, an exit status is a 0-255 byte (despite the int entry point return), but on Windows an exit status, for both threads and processes, is a 32-bit DWORD. On an abnormal exit, Windows provides a status indicating what went wrong, which you can recognize by 0xc000????. We can see that in the last case, where that special code corresponds to "illegal instruction." [...] There are many gaps in behavior between unix and Windows like this, and busybox-w32 makes helpful accommodations such as this. Getting a loud message for unusual exist statuses is great, and I've been happier since its introduction. Why 0xffffffff? Dig into cliconst.h and you'll find: #define ERROR_RET_CODE -2 #define WARNING_RET_CODE -1 That is, elena64-cli is indicating a warning occurred, which you can see mentioned in its output, by exiting with -1. It's not an error, so you can ignore it. Indeed if you look in the rebuild script, it's looking for that error status specifically: if [ ret -eq 2 ] Except, oops, the sign is wrong! This is a rebuild script bug, and so it cannot actually detect errors on Windows despite being a Windows-specific script. On platforms that don't include windows.h, the above #defines are positive. The 0xffffffff message from busybox-w32 indicates that no error occurred, so we can check what the script missed. [...]

The .bat scripts check for negative codes, and cmd %ERRORLEVEL% interprets exit statuses as signed 32-bit, so they're fine. The mismatch is between Windows builds and the .sh scripts. Looking at e289580, the divergence seems to be a result of noticing the unix build scripts weren't detecting warning nor exit statuses (because exit statuses are always positive), and so these codes were flipped to positive on unix only. IMHO, unifying exit statuses to positive everywhere would improve things while also reducing the amount of code. Note that this time your error is 0xfffffffe, e.g. -2, so there was an actual build error, the details of which you didn't share. The .sh build script didn't notice the error because it's looking for "-eq 2" but fortunately busybox-w32 warned you about the weird exit status (e.g. not in the usual 0-255).

[arakov]

Now I see what can be an issue. So I've modified my code to be compatible with C++ 23 exit code. Now an error in the compilation will return 1 and the warning 2