Please restore Android support to the vendored Angelscript

[robertkirkman]

When compiling the newest SimulIDE-dev for Android, this link error occurs:

ld.lld: error: undefined symbol: CallSystemFunctionNative(asCContext*, asCScriptFunction*, void*, unsigned int*, void*, unsigned long&, void*)
>>> referenced by as_callfunc.cpp
>>>               build/objects/as_callfunc.o:(CallSystemFunction(int, asCContext*))
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:1815: executables/SimulIDE_2.0.0-/simulide] Error 1

I have determined through calculating the preprocessor macro evaluations that the reason why CallSystemFunctionNative() is not defined on Android in the version of Angelscript present in the github.com/eeTools/SimulIDE-dev/src/angel folder is because you have deleted this line, and many other Android-related lines, from your Angelscript code before committing it to your repository:

https://github.com/anjo76/angelscript/blob/a21fd7965a4d435d52bb1082781d5578f7430b1d/sdk/angelscript/source/as_config.h#L1181

@Arcachofo The reason that I know you deleted Android-related code from your fork of Angelscript before uploading it is because the copyright date of Angelscript in SimulIDE-dev is 2021, but the code was already present in upstream Angelscript at a date before 2021:

SimulIDE-dev/src/angel/src/as_config.h

Line 3 in 21555b7

Copyright (c) 2003-2021 Andreas Jonsson

https://github.com/anjo76/angelscript/blob/20fc849f5fc2616897c117842e27882ff88c378d/sdk/angelscript/source/as_config.h#L1078

Please undo the removal of the Android-related code from the vendored copy of Angelscript. Thank you.

You don't need to test it, I will do that part, but if you don't want to make changes without understanding how to test them, but you are willing to learn how, let me know and I would walk you through the steps to reproduce the error ld.lld: error: undefined symbol: CallSystemFunctionNative.

[Arcachofo]

Hi @robertkirkman
Didn't know about Termux, cool project.

First note that last stable version is here:
https://git.launchpad.net/simulide

Android is not supported by now, but if you make it work I can add it.

In any case, shouldn't the Linux configuration work for you?

[robertkirkman]

In any case, shouldn't the Linux configuration work for you?

unfortunately, no, at least not without some changes, which might be small but might also be large, depending on what ends up being required.

In this case, the difference between the definition of "Linux" and the definition of "GNU/Linux" actually matters, so unfortunately, your deletion of this line containing an instance of the preprocessor macro __ANDROID__ from your fork of Angelscript has removed compatibility with Android, which includes Termux.

https://github.com/anjo76/angelscript/blob/20fc849f5fc2616897c117842e27882ff88c378d/sdk/angelscript/source/as_config.h#L1078

The name of the operating system that your project actually supports is technically "GNU/Linux".

Since I understand that your project does not officially support Android and you did not imagine the possibility of anyone ever using it on Android at the time when you developed the Angelscript fork, you might not exactly remember everything that you deleted from your Angelscript fork in the past related to Android support anymore, which would be understandable.

I will eventually try to undo the deletion of the Android support code from the Angelscript fork found in this repository by attempting to perform a calculation that will show me exactly all of the invisible changes that you made while forking Angelscript before committing it into this repository.

First note that last stable version is here:
https://git.launchpad.net/simulide

Thank you, however, I can see that unfortunately, the same limitation also applies to that version:

https://git.launchpad.net/simulide/tree/src/angel/src/as_config.h

In that version, the fork of Angelscript from which some of the lines related to the preprocessor macro __ANDROID__ have been deleted also already exists.

[robertkirkman]

I have not mentioned yet, but I should, for context, that the SimulIDE version 0.4.13-SR5-CE located here: https://github.com/SimulIDE/SimulIDE/tree/4bf26bc839147551a00938aa2949012681a3e046 currently works in Termux, so really my goal is not entirely to port SimulIDE to Android from scratch as if it had never been done before, but is actually to update that version of SimulIDE in Termux to the newest version because a user of SimulIDE in Termux wants the newest version.

The reason why that SimulIDE version 0.4.13-SR5-CE works in Termux but the version in this repository which this issue is in does not, is because that SimulIDE version 0.4.13-SR5-CE does not contain the modified fork of Angelscript from which Android support has been deleted.

[Arcachofo]

I think the only thing related to Android that I removed is only those lines in the preprocessor macro.

I would try to add that section and see if it works.

[robertkirkman]

Thanks, I have been trying that now, and it's helpful to know that the only thing specifically related to Android that you can remember removing is the lines from as_config.h. I'm attempting to make progress by making that assumption, then attempting to make modifications based on it and try compiling again.

However, unfortunately, I started to encounter other errors afterward, and these other errors are related a bit more to the CPU architecture specifically, I think, rather than the differences between operating systems. I see these errors now:

as_callfunc_arm64.cpp:(.text+0x16c): undefined reference to `CallARM64Double'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x634): undefined reference to `CallARM64RetInMemory'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x6c4): undefined reference to `CallARM64Ret128'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x704): undefined reference to `CallARM64'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x77c): undefined reference to `CallARM64'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x79c): undefined reference to `GetHFAReturnDouble'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x7a4): undefined reference to `CallARM64Float'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x7ec): undefined reference to `GetHFAReturnDouble'
/usr/bin/ld: as_callfunc_arm64.cpp:(.text+0x7fc): undefined reference to `GetHFAReturnFloat'
collect2: error: ld returned 1 exit status
make: *** [Makefile:1805: executables/SimulIDE_2.0.0-/simulide] Error 1

One of the reasons I can tell that these errors are related more specifically to the CPU architecture than to the differences between operating systems, is because when I try to compile SimulIDE-dev on ARM GNU/Linux, instead of on ARM Android, I see these same errors, indicating that SimulIDE-dev can be affected by these new errors on multiple operating systems, if they are running on an ARM CPU rather than an x86 CPU.

ARM GNU/Linux is just a little bit more obscure operating system than ARM Android and x86 GNU/Linux both are, but it is not completely theoretical either and does have some support broadly from other software. The two most popular and widely-used devices that ARM GNU/Linux is often found on are probably Raspberry Pi boards, and Apple Silicon Macs that have had Asahi Linux installed on them.

When I take a look at possible causes of these new errors, I think they probably have to do with this other line of code I see in the upstream Angelscript, also having been removed, or just having no equivalent currently, in the vendored fork of Angelscript I see here in SimulIDE-dev:

https://github.com/anjo76/angelscript/blob/a21fd7965a4d435d52bb1082781d5578f7430b1d/sdk/angelscript/projects/cmake/CMakeLists.txt#L141

This indicates to me that, even after resolving the first errors I encountered, SimulIDE-dev will probably not be possible to compile successfully for either the average Android phone, or the average Raspberry Pi, until some way to resolve these additional errors is created.

I will try to figure out some way to do that next, I just wanted to give an update so that you are aware of this situation involving the problem of support for devices that have ARM CPUs in general, regardless of operating system, in the current SimulIDE-dev.

Since these additional errors are, unlike the first errors I encountered, not strictly speaking specific to only Android, I could open a separate issue to track them separately if you want, but just let me know if you feel that's necessary.

[robertkirkman]

Oh I see, I went back to the issue list and searched again, and now I see that there is already a tracker for this here:

• Fix ARM build. #19

I'll keep that in mind, hopefully I will be able to figure out some way to resolve that for at least ARM GNU/Linux if nothing else, and if I think I have, I'll let you know.

[robertkirkman]

I've managed to create some downstream workarounds that might be working to prevent all the errors I encountered (except for the error in commit bf9d91f that has only been introduced recently, but I am sure that is temporary and you will make some more updates soon to fix it, so I'm building the commit from the day before yesterday)

If you are interested in this kind of thing and want to look, you can click the recent GitHub mention link to see the downstream-specific implementation -

I'm not sure how much of it are things that you would want in upstream here (would you want support for both ARM cross-compilation and ARM native compilation or just ARM native compilation? Both GNU/Linux and Android or just GNU/Linux? Both 32-bit and 64-bit or just 64-bit?), and the builds haven't been tested by experienced SimulIDE users yet,

so I'll try to have our downstream users test the new builds at least for a while, to figure out how well they work and whether there are any additional issues at run-time now that all the build-time issues have been fixed, and after a while if you would like PRs, I can eventually try to open PRs for fixes that you would consider desirable for upstream.

[Arcachofo]

@robertkirkman thank you for fixing this problem.

32-bit systems are not supported anymore.
Cross-compiling and Android are good things.

I applied your patches (excluded ARM32) but I can't test.
If you find any problem please let me know.

[robertkirkman]

32-bit systems are not supported anymore.

ok, thanks for explaining, I will maintain the 32-bit builds only in downstream then, and I will not report any issues upstream that are only reproducible on 32-bit devices.

I applied your patches (excluded ARM32) but I can't test.
If you find any problem please let me know.

Oh no, I didn't mean for you to immediately commit all the changes as-is,

Some of the changes were downstream-specific, and might not work appropriately in upstream without further revision.

Don't worry though! I will test the changes and open an upstream PR here ASAP to implement any necessary further changes in a way that seems appropriate for upstream.

It should be noted that unfortunately, QMake does not seem to have very complete support for reliable detection of cross-compilation, at least not like the original CMake of upstream Angelscript does. The downstream implementation of cross-compilation I wrote might not completely work in isolation, since it depends on external code in the repository I committed it to. Therefore, I might unfortunately not know how to completely implement cross-compilation detection in this repository github.com/eeTools/SimulIDE-dev in a generalized way, but I will still try.