`lime rebuild <lib> android` command is not working

[Sirox228]

When calling lime rebuild <lib> android lime says that i need to specify an architecture HXCPP_ARM64, HXCPP_X86 etc... but no matter the architecture i specified (with -D option) it builds for all 4 architectures and because of that, compilation would die in absolutely any lib, is there any way to solve this problem with specifying architecture? (i clearly remember, that +- 1 year ago, i was able to rebuild without specifying an architecture and it was fine)

[player-03]

This error comes from android-toolchain-clang.xml, which is automatically enabled when using NDK 20+. It isn't actually complaining about those four architectures, but about the fifth that Lime tries to compile: armv5. I'm pretty sure armv5 is so old that HXCPP just decided it wasn't worth supporting anymore.

Theoretically if you specify an architecture, it should target that alone and not try to build for v5, but I'm not sure Lime is consistent about that.

Anyway, to resolve this issue, you have two options: go back or go forward. To go back, you'll have to revert all the way to NDK r15c (r16-r19 are incompatible for multiple reasons). To go forward, checkout #1531, then run git submodule update && lime rebuild tools && lime rebuild android.

[player-03]

You'll need Git, but on the plus side, I'm pretty sure it automatically updates submodules.

> haxelib git lime https://github.com/player-03/lime.git submodules
> lime rebuild tools
> lime rebuild android
> lime rebuild <lib> android

[Sirox228]

it seems that pixman is even more dead than usual now... this happened ./lib/cairo/src/cairoint.h:71:10: fatal error: pixman.h: No such file or directory 71 | #include <pixman.h> | ^~~~~~~~~~ compilation terminated.

P.S. i'm trying to build it in github actions on ubuntu, maybe thats why? P.S. N°2 - i just tried to compile on my windows pc and is fully working, even for android, but in github actions, on ubuntu, it dies when rebuilding tools with the same pixman.h not found error

[player-03]

It didn't update submodules? That's so weird. Either that or it failed to check out the right branch.

~~Ok, let's get some more data.~~

1. ~~Navigate to /lime/git (or /lime/submodules if that's what it thought the "submodules" argument meant).~~
2. ~~Run git branch to check what branch you're on. If you aren't on submodules you'll want to switch to that using git checkout submodules.~~
3. ~~Run git submodule update.~~
4. ~~Ensure that project/lib/cairo-files.xml does exist, and that project/lib/cairo/files.xml does NOT exist.~~
5. ~~Rerun the above commands.~~

Ugh, you're using Actions, which means you can't do it interactively. Fine, new plan. This will require multiple runs.

1. For the first run, just get the install path.

   $ haxelib git lime https://github.com/player-03/lime.git submodules
   $ haxelib path lime
   

2. Now navigate to that path and print some data.

   $ haxelib git lime https://github.com/player-03/lime.git submodules
   $ pushd [path-to-lime]
   $ git branch # "submodules" should be highlighted
   $ ls project/lib/cairo-files.xml # should print the file
   $ ls project/lib/cairo/files.xml # should say "no such file or directory"
   $ grep -n "#include <pixman.h>" project/lib/cairo/src/cairoint.h # should print line 69, not 71
   $ popd # optional cleanup
   

Post your results here, and we'll figure out where to go from there.

[Sirox228]

thats the result of first one:

-L /opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git/ndll/
--macro lime._internal.macros.DefineMacro.run()
/opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git/src/
-D lime=8.0.0

and in second one, for some reason it's just can't find the dir in pushd ._. (i tried to add '/' to the end of the path, but nothing changed)

/home/runner/work/_temp/ef4c6853-06fe-4ab9-b700-becfa21bb988.sh: line 3: pushd: [/opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git]: No such file or directory

[player-03]

That's strange. Uh... I guess let's find out what does exist.

$ pwd
$ ls .
$ ls /opt
$ ls /opt/hostedtoolcache
$ ls /opt/hostedtoolcache/haxe
$ ls /opt/hostedtoolcache/haxe/4.2.5
$ ls /opt/hostedtoolcache/haxe/4.2.5/x64
$ ls /opt/hostedtoolcache/haxe/4.2.5/x64/lib
$ ls /opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime
$ ls /opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git

[Sirox228]

git
CHANGELOG.md
CONTRIBUTING.md
Dockerfile
LICENSE.md
NOTICE.md
README.md
assets
dependencies
docs
externs
extraParams.hxml
haxelib.json
haxelib.xml
hxformat.json
include.xml
lime.png
ndll
package.json
project
run.n
src
svg.n
templates
tests
tools

there's lime directory..... pushd just can't find it.... maybe it browses current working directory even if path is starting from '/'?

[player-03]

pwd prints out the working directory. Can you use that to construct a relative path?

While you're at it, try using cd instead of pushd. (And instead of popd, manually cd back to the original directory.)

[Sirox228]

ok, i was just VERY "clever " and made pushd command like that:

pushd [opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git]

now removed [] and is working here's the log:

Installing lime from https://github.com/player-03/lime.git branch: submodules
Library lime current version is now git
/opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git ~/work/extension-ffmpeg/extension-ffmpeg
  develop
* submodules
project/lib/cairo-files.xml
project/lib/cairo/files.xml
71:#include <pixman.h>
~/work/extension-ffmpeg/extension-ffmpeg

[player-03]

Ok, that's simple. It failed to update submodules, which really should have been my first guess. But this debugging wasn't wasted, because we did need to know Lime's path.

$ haxelib git lime https://github.com/player-03/lime.git submodules
$ git -C /opt/hostedtoolcache/haxe/4.2.5/x64/lib/lime/git submodule update
$ lime rebuild tools
$ lime rebuild android
$ lime rebuild <lib> android

Haxelib did install the submodules, which is cool. Problem is, it installed the version for the default branch. I'm guessing it does things out of order: clone the default branch, then download submodules, then switch to the requested branch. Annoying but fixable.

[Sirox228]

i just made same thing with cd and it showed this:

fatal: not a git repository (or any of the parent directories): .git

and i just understood that haxelib git remove .git folder, so git cannot be used there

[Sirox228]

just made as you said and this happened

fatal: remote error: upload-pack: not our ref b43e7c6f3cf7855e16170a06d3a9c7234c60ca94
fatal: Fetched in submodule path 'project/lib/cairo', but it did not contain b43e7c6f3cf7855e16[17](https://github.com/Sirox228/extension-ffmpeg/actions/runs/3222078761/jobs/5270757278#step:3:18)0a06d3a9c7234c60ca94. Direct fetching of that commit failed.

[player-03]

haxelib git remove .git folder

I have never seen it do that. However, hidden folders won't show up in a simple ls; you have to use ls -l.

---

If it really does delete .git, then you'll need to clone by hand.

$ git clone --single-branch --branch submodules --recurse-submodules https://github.com/player-03/lime.git ../lime
$ haxelib dev lime ../lime

Plus side, it will clone the correct submodules this way.

---

just made as you said and this happened

Weird. Maybe you needed to rerun submodule init as well? But that shouldn't be it.

Anyway, I think at this point it's far easier to clone it yourself, as described above.

[Sirox228]

another one now

Error: ./lib/openal/alc/backends/alsa.cpp:54:10: fatal error: alsa/asoundlib.h: No such file or directory
   54 | #include <alsa/asoundlib.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.

i gitted it with my hands as you said

[player-03]

Looks like you got the correct submodules. I've never seen this new error (not even in GitHub actions). Maybe there's a compilation flag that's wrong.

I'll look into this later.

[Sirox228]

i just browsed the openal repo from which your lime gits openal and there's no asoundlib.h file, how it's normally compiling on windows, i'm confused ._.

[player-03]

It's been so long since I set this up, I forgot the steps. Fortunately, I wrote them down. As you can see in the "prerequisites" section, you need libasound2-dev (among others) to build on Linux.

[Sirox228]

thanks, now it works, i think that we can close issue.

[Sirox228]

someone from the people that used lib i rebuilded as you said got this error, i think it occurs only on armv7, because for me there's no such issue (i'm on armv8a)

[player-03]

I don't remember the exact details of DLL loading, even though I did have to debug it once.

I'm not sure the exact symbol is important; there's a good chance that it just can't find any system DLLs. To be clear: liblime.so doesn't define __atomic_fetch_sub_4, it references it. It expects the system to provide the definition. Android includes several DLLs containing standard symbols like this, for both 32 and (if the device supports it) 64-bit code.

I recall that the 32-bit DLLs are stored in a different folder than the 64-bit ones, but I forget which folder and can't seem to find it via web search. Back when I was running into this error, the problem might have been loading the wrong folder. Either that or I was compiling the app for the wrong architecture, and that caused it to load the wrong folder.

I wish I could remember this stuff more clearly.

[Sirox228]

i think that system/lib is that directory for 32 bits libs you're talking about (system/lib64 is for 64 bits) you can try setting system_ext or vendor instead of system there are those libs dirs, but i don't sure that are same, so maybe only 1 of them would work

[ghost]

hi, im here to aport to this issue, something similar happened to me while trying to startup a haxe app with (c) code that used atomic. so i went to compare the atomic symbols in the haxe app and my libc, and i found out that actually my libc had almost no atomic symbols. (libapplicationmain is from the haxe app) so, i tried using + compiling and running the (c) code that i tried to load in the haxe app in termux and first of all, the binary didnt have any symbol issue, and didnt use any atomic symbol, and it worked as expected, i guess that this is an ndk/api issue?. im willing to give more detail to fix this issue. device info: android 9, armv7a. termux: using clang compiler v15, api 24 as target, ndk r25 headers. haxe app: built with ndk r21e.

[Sirox228]

@player-03 is there a way to compile using ndk r25b? it seems that atomic error comes from r21e and is fixed in new ndk. I'm with help from Randomxdp tried to make hxcpp for ndk r25b by completely cutting gcc from it and using only clang xml and copying all needed defines from gcc xml to clang xml and we almost done it, but faced pcre_compile.c death that we can't find how to fix:

hxcpp/project/thirdparty/pcre-8.42/pcre_compile.c:7252:28: error: cannot initialize a variable of type 'named_group *' with an rvalue of type 'void *'
              named_group *newspace = (PUBL(malloc))(newsize * sizeof(named_group));
                           ^          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

for some reason it thinks that PUBL(malloc) is 'void *', i checked ndk source code and malloc function is 'void *' type in both r21e and r25b. Do you either know the way to run r25b or how this error can be fixed?

[player-03]

So I found someone else with the "undefined reference to __atomic_exchange_4" error. For them, all they had to do was specify -latomic. ~~But I don't know if it's that easy here. Setting -latomic gives instructions to the linker, but these apps already make it through the linker step just fine. It isn't until runtime that it finds the issue.~~ Edit: I've been informed that this might be wrong.

Still ~~might be~~ worth looking into; check your device to see if it has a dll or shared object named "atomic."

[player-03]

Currently Pixman is preventing us from using NDKs newer than r21e, and they aren't in any rush to fix the issue.

Edit: besides, you can safely ignore the GCC toolchain file. The Clang file is already complete and working, so don't go copying stuff over unnecessarily.

[Sirox228]

Currently Pixman is preventing us from using NDKs newer than r21e

i can't say for sure, but maybe compiling pixman with make using r25b and then linking pixman.a to lime rebuild should fix this issue. I'm gonna try

[Sirox228]

i just tried to compile it with ndk-build and faced the same issue as in lime rebuild, but i checked what causing errors and found out that it's neon code, neon is just a thing that optimizes code a bit, it isn't necessary, so i removed it from the build and it's normally compiled.

[player-03]

Ah, cool. Glad to have another pair of eyes on this.

Though my advice is not to remove the Neon-related lines, but instead set unless="NDKV22+". (Obviously use || if there's already an unless condition.) That way, we get the best of both worlds: people who care about pixel manipulation performance can revert to NDK r21e, and everyone else gets to use the latest NDK.

[Sirox228]

Though my advice is not to remove the Neon-related lines, but instead set unless="NDKV22+".

i just made those changes and pull requested you in your lime repo

[player-03]

Thanks!