tobil4sk
tobil4sk
> One possible option is for lime.ndll to have a hardcoded full path to libneko (by setting install_name). Here is a hacky patch that implements this solution: https://github.com/tobil4sk/lime/commit/a308fe725950eb25da3ee98ee99982f9a62a479a
> One possible option is for lime.ndll to have a hardcoded full path to libneko (by setting install_name). [...] Also, this would only work if lime.ndll is compiled with -lneko...
Reopening because the server still runs on Haxe 3... The legacy server would require some changes to compile with Haxe 4, or we can keep just that on Haxe 3.
So, it seems HXCPP uses [UTF16 for unicode strings](https://haxe.org/manual/std-String-encoding.html), so that would make sense why it doesn't work if UTF8 is expected. Looks like this problem was solved for Windows...
#1472 seems to resolve this issue.
Yes, hopefully it can be merged soon.
This will cause issues with #1661. I think it might be good if the code for deciding whether to use hl or neko (or cpp) is moved here, where it...
> As an HXP project user, I wouldn't want to put this in ProjectXMLParser. Ah, right I completely missed that... yes then it probably should all be cleaned up and...
> (Note that this only works with the haxelib releases, a development build on Linux won't have HL Windows binaries) Similar situation with MinGW currently. The haxelib release provides a...