I'm using Angelscript 2.22.1 in a game I'm porting to Linux.. The release game distributes JUST the compiled angelscript byte code, however this isn't working correctly on x86_64 linux. Here is the breakdown of what it's doing.

32bit linux loads the bytecode generated by the 32bit linux game binary,, does NOT load the bytecode generated by the 64bit binary
64bit linux does not load either bytecode correctly.

Does the bytecode depend on how the calls are registered? As some calls are wrapped (using the autowrapper) on x86_64 linux only. (they use Native calling on all other platforms). This is to work around the passing and returning of certain structs by value.

Version 2.22.1 did not yet have a platform independent bytecode, this was only implemented in version 2.23.0.

In version 2.22.1 Linux 64bit should be able to load bytecode compiled on Windows 64bit and vice versa, as should Linux 32bit be able to load bytecode from Win 32bit and vice versa. Linux 64bit won't be able to load Linux 32bit bytecode, and vice versa.

The bytecode does not depend on the registered functions' calling convention, as long as they are registered with the same declaration, the bytecode loader should work correctly.

I'm not aware of any bugs in version 2.22.1 that causes bytecode not to load properly on Linux 64bit. The bug fixes that have been done in later releases are all related to the changes done in version 2.23.0 to make the code platform independent.

Would it be possible to narrow down the script that fails to load properly, so that I can try to determine the cause of the failure? Unfortunately I do not have access to a 64bit Linux environment to test the library on anymore, since Jeremy's not responding anymore, but depending on the situation I may be able to figure out the cause anyway.

Andreas, if its of any help debugging this issue, test_feature doesn't fail but reports the following on x86_64 OS X:

The saved byte code is not of the expected size. It is 1888 bytesThe saved byte code contains a different amount of zeroes than the expected. Counted 620The saved byte code has different checksum than the expected. Got 0xCC85F81D-- TestSaveLoad passed

Hi quarnster, this tells me that there is indeed something wrong in the 64bit save/load feature. I'll try to see if I can reproduce this on my Win64 machine. Hopefully it is the same problem that urkle is facing.

I managed to get access to a 64bit Linux environment to try this on. Unfortunately I was not able to reproduce the problem, neither with version 2.22.1 nor with the latest revision from the SVN.

There are a few minor issues with the latest revision from the SVN that I'll check in tonight, but they are unrelated to bytecode saving/loading.

I will need more information to be able to fix this problem.

First, will you be working with the latest release or stick with version 2.22.1? For me the latest would be best, but I understand if you'd prefer to stick with the version already used by the game on other platforms.

Second, I really need for you to narrow down the script that is failing to load, so I can debug it in my own environment in order to figure out the problem. Try commenting out part of the script, then test the save/load part. If it still fails, comment out more of the script, it it doesn't fail, uncomment the script and comment the other part instead. With a few iterations like this you should be able to get a reasonably small script.

I understand the problem shows immediately as the script is loaded, i.e. the LoadByteCode() method returns an error, and not just when running the game, right? This ought to make it easier to pinpoint the problem.

I backported the tests that I have for the latest WIP to version 2.22.1 and some of the problems that have been fixed in the latest releases were already pre-existent in version 2.22.1 even before the major changes in 2.23.0.

The situations that I found out that fails on 2.22.1 are the following:

- Arrays initialized with function pointers (fails to properly store the function pointers that the array is initialized with)
- Non-shared classes that inherit from shared classes (fails when loading the second module with the same shared class)

However, both of these problems also occur on 32bit so I do not believe they are related to the problem you're facing with Linux 64bit. I won't work on fixes for these problems in version 2.22.1, unless it is determined that they really are what is causing your problem.

I've reproduced the problem on the latest WIP and will be working on the fix. However, the same scenario is working OK in version 2.22.1, so it doesn't seem to be the cause of the problem that urkle reported.

The bytecode saves out ok from 64 bit now.Unfortunately I'm still having issues with loading bytecode on 64 bit.

The bytecode seems to load ok and it runs, but when it executes a function with an enum parameter, the other parameters get mangled.For example, I have a script function:

void change_state(state_types new_state, int new_face)

When the scripts are compiled on x64 it works fine, but when the bytecode is loaded again, the second parameter becomes the same value as the enum.Replacing state_types with int then casting it back to an enum to assign it fixes the problem.There was another case with a few enums and a string that caused a crash in the string assignment operator when the function was called. This was also fixed by replacing the enums with ints.The function I was originally having problems with also causes problems, so I'm assuming this is the same problem but manifesting itself in a different way.

I'll see if I can isolate the problem again, I suspect it will just be a matter of reloading the bytecode in the test I posted earlier.Edit: Yep, using the same script as before but saving then loading the bytecode before executing it causes a crash, but it works if the enum is swapped for an int.

Thanks Andreas,
I was having the same issue with revision 1373, but I made the same changes in asCWriter::CalculateAdjustmentByPos() and asCReader::CalculateAdjustmentByPos()
And everything seems to be working now!
Does that sound right?