The Windows version of the application does not work if it is built on linux

[Timofei302]

I tried to build a game on linux for Windows. As a result, the NekoVM application was built, which does not start. I tried to build a game with the keys -cs, -cpp, -hl, but in the end a non-working NekoVM application was compiled anyway.

No errors appeared during compilation.
The project works if it is compiled for Linux.

Startup errors (translated to English):
Windows 10 64x (not my pc):

Linux (via Wine Staging 8.18):

1. This error appears first:
   
2. Then this error appears many times:
   

Technical information:

• OS: Manjaro Linux
• Haxe Version: 4.3.1
• OpenFL Version: 9.3.2-L3m3oj
• Lime Version: 8.1.1

[Timofei302]

This app build:
bin.zip

[player-03]

Last time someone looked at this, they found that Neko outputs a Linux executable with a .exe suffix. Basically, cross-compiling isn't supported and no one noticed. Can you test with #1610 and/or #1661?

[Timofei302]

Last time someone looked at this, they found that Neko outputs a Linux executable with a .exe suffix. Basically, cross-compiling isn't supported and no one noticed. Can you test with #1610 and/or #1661?

I will try to check #1610

[Timofei302]

idk why, but when trying to execute lime rebuild linux, compilation fell with a large column of errors, and after compiling from the develop branch, the rebuild attempt began to fail with this error:

But if you switch back to the develop branch, then lime rebuild linux starts working correctly again.

[player-03]

Run git submodule update after switching branches. (If the submodule folders are empty, add --init to the end of the command.)

[Timofei302]

Run git submodule update after switching branches. (If the submodule folders are empty, add --init to the end of the command.)

[Timofei302]

And again something breaks. Now I'll try to fix it

[Timofei302]

It didn't work out. Compilation began to be interrupted due to errors.

[player-03]

Ah, right. Someone brought up this issue at one point and I said I'd have to implement a workaround, but then for some reason we decided it wasn't actually an issue? I don't know why we decided that.

The problem is that we updated the remote URL, and Git doesn't keep track of that, or provide and I couldn't find any way to tell it "hey the remote URL changed, check it again." You'd think deleting and reinitializing the submodule would do it, but nope. Your options are (1) delete and clone the entire Lime repo again (every time you want to switch branches) or (2) update the URL by hand.

To update the URL, open a terminal and navigate to the curl folder. From there, run the following in order:

git remote add upstream https://github.com/curl/curl.git
git remote add legacy https://github.com/openfl/libcurl.git
git fetch
cd ..
git submodule update

Edit: fixed the legacy URL. I had an even older one on record.

[Timofei302]

The method of updating the URL did not help (it may have messed up the local repository with attempts to fix the problem). Now I will try to clone the repository again, but immediately with the right branch.

[joshtynjala]

Running both of these commands always works for me when I switch branches that have different remotes for submodules:

git submodule sync
git submodule update

[Timofei302]

Running both of these commands always works for me when I switch branches that have different remotes for submodules:

git submodule sync
git submodule update

Thanks! It worked!

[Timofei302]

Rebuild for linux was successful. But rebuild for windows gets stuck with a field of many continuous warns.

[player-03]

I don't think rebuilding for Windows would help. lime rebuild recompiles the build tools themselves, and you can't exactly use Windows build tools to compile on Linux.

Just rebuild for Linux, then try your build again.

[Timofei302]

`lime rebuild linux' leads to nothing.

When trying to rebuild windows, a lot of warns appear:
lime_rebuild_windows.txt

If you are not rebuilding for Windows, then for obvious reason the project is also not compiled.

[player-03]

If lime rebuild linux prints nothing, it means you already rebuilt successfully, and you're ready to go to the next step. Though if you aren't sure, you can always do lime rebuild linux -clean.

[Timofei302]

Attempt to execute lime rebuild windows -hl fails with an error:

Error: ./lib/hashlink/src/std/buffer.c: In the function «hl_buffer_rec»:
./lib/hashlink/src/std/buffer.c:378:17: error: unsupported non-standard concatenation of string literals
  378 |                 hl_buffer_str_sub(b, buf, usprintf(buf, 32, _PTR_FMT USTR("H"),(int_val)v));
      |                 ^~~~~~~~~~~~~~~~~
./lib/hashlink/src/std/buffer.c:378:17: error: unsupported non-standard concatenation of string literals

[Timofei302]

And lime still refers to the ndll file, even if you specify the -hl key

[player-03]

Interesting. Is it trying to use that to compile? Because it definitely shouldn't. But it says "source path," so maybe it just wants to include the ndll in the build, which ought to be fine.

In that case, all you need to do is copy ndll/Windows64/lime.ndll from a Haxelib release. (Use lime --version to check which version you're currently using, then download that version from Haxelib.)

[Timofei302]

Interesting. Is it trying to use that to compile? Because it definitely shouldn't. But it says "source path," so maybe it just wants to include the ndll in the build, which ought to be fine.

In that case, all you need to do is copy ndll/Windows64/lime.ndll from a Haxelib release. (Use lime --version to check which version you're currently using, then download that version from Haxelib.)

bruh. it exactly ignores -hl for windows