Open Timofei302 opened 8 months ago
This app build: bin.zip
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?
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
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.
Run git submodule update
after switching branches. (If the submodule folders are empty, add --init
to the end of the command.)
Run
git submodule update
after switching branches. (If the submodule folders are empty, add--init
to the end of the command.)
And again something breaks. Now I'll try to fix it
It didn't work out. Compilation began to be interrupted due to errors.
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.
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.
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
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!
Rebuild for linux was successful. But rebuild for windows gets stuck with a field of many continuous warns.
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.
`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.
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
.
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
And lime still refers to the ndll file, even if you specify the -hl
key
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.)
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
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):![2023-11-12_161530](https://github.com/openfl/lime/assets/59145732/739f0843-00e7-4d8a-8452-37a8ca1b670a)
Linux (via Wine Staging 8.18):
Technical information: