J2V8
J2V8 copied to clipboard
Doesn't run anymore on Android 4.4
It used to work on android version 4 but I just updated and now I get : cannot locate symbol "sigemptyset" referenced by "libj2v8.so"
cc @irbull
I am getting this as well, reads like it was intentional according to the comments starting here, but maybe open to lowering the level to support API 16+ on 32-bit?
Fatal Exception: java.lang.IllegalStateException: J2V8 native library not loaded (j2v8-android-arm_32/j2v8-android-arm_32)
at com.eclipsesource.v8.V8.checkNativeLibraryLoaded(V8.java:257)
at com.eclipsesource.v8.V8.createV8Runtime(V8.java:153)
at com.eclipsesource.v8.V8.createV8Runtime(V8.java:114)
Caused by java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "sigemptyset" referenced by "libj2v8.so"...
at java.lang.Runtime.loadLibrary(Runtime.java:364)
at java.lang.System.loadLibrary(System.java:526)
at com.eclipsesource.v8.LibraryLoader.loadLibrary(LibraryLoader.java:82)
at com.eclipsesource.v8.V8.load(V8.java:75)
at com.eclipsesource.v8.V8.createV8Runtime(V8.java:149)
at com.eclipsesource.v8.V8.createV8Runtime(V8.java:114)
We are seeing this with the following OS versions:
- 4.4.4
- 4.4.2
- 4.2.2
- 4.0.4 (realize this will have to be dropped)
Reference: #174 #384 cannot find symbol sigemptyset
We have the same problem here. Do you have an idea to solve it?
Thanks
I have not, short of doing a local build which I am hesitant to do until we hear back on whether this will be backported to support API 16+.
This seems important. Can anyone shed some light on 64 vs 32 bit on 4.4? Is it only 32 bit we need or does 4.4 also require 64 bit builds?
@mpost Have you tried with 4.4? @elshadsm do you think you can try and build for 4.4?
And about API 19+, have your tried this ?
APP_PLATFORM := android-19
in your Application.mk
Ref:
The cause of problem is not the version of NDK that was used but version of target platform. android-19 is the last platform version where sigemptyset() (and many other functions) was declared as inline just at platform headers. As result - system libc on that devices doesn't contain such functions.
The issue is here: (config_android.py) "android-gcc-toolchain $ARCH --api 21 --host gcc-lpthread -C". Changing that to 19 will resolve the issue though should probably be performed only for the 32bit build iterations. On Wednesday, May 22, 2019, 10:39:41 AM GMT+3, Nicolas M [email protected] wrote:
And about API 19+, have your tried this ? APP_PLATFORM := android-19 in your Application.mk
Ref:
The cause of problem is not the version of NDK that was used but version of target platform. android-19 is the last platform version where sigemptyset() (and many other functions) was declared as inline just at platform headers. As result - system libc on that devices doesn't contain such functions.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
The issue is here: (config_android.py) "android-gcc-toolchain $ARCH --api 21 --host gcc-lpthread -C". Changing that to 19 will resolve the issue though should probably be performed only for the 32bit build iterations.
☝️ Additionally should update it here for consistency
I am under the same requirements to support older androids. Is there any chance it will be supported?
@irbull Do you have news about this? thank you so much
@irbull Is the android --arch arm64
build on docker intended to be working from master?
I built arm with android-gcc-toolchain $ARCH --api 19
and arm64 with android-gcc-toolchain $ARCH --api 21
then manually updated the arm64 aar with arm build libs.
For me, build with -- API 19 on latest master, didn't worked well when I run on old devices. I end up building hybrid aar. I took latest 4.4.8 aar and repackage it with 32 bit .so files from version before. And it working well so far. It is in production for almost a week already with no issues. Anyway, thanks for the response.
Interesting, my local build is working in testing, but merged aar from last 2 releases is crashing with newer API's.
+1 on this issue. Can you please help to provide fix?
Tried pulling 32 bit libs from 4.6.0
and added to aar of 4.8.4
and 5.0.103
but it crashed because of other symbols not found on API 19
Try to pull 32 bit .so files from 4.8.2 and add them to aar of 4.8.4. This is what worked for me
I have a local build working in testing so far, but would prefer an official build/support prior to the Aug 1 deadline set by Google.
More interestingly, I have built with android-gcc-toolchain $ARCH --api 16
and the build output aar includes 32bit and 64bit libs and working in testing.
Unfortunately pull 32 bit .so files from 4.8.2 and add them to aar of 4.8.4
didn't worked for me!
@doneill can you please share build steps, otherwise I will try to follow build steps for Android from https://github.com/eclipsesource/J2V8/blob/master/BUILDING.md.
I have tried a few things, first I built 2 separate libs changing the toolchain arch in config_android.py to the min API I wanted to support:
e.g. built x64 libs with
"""android-gcc-toolchain $ARCH --api 21 --host gcc-lpthread -C \
and build x32 libs with
"""android-gcc-toolchain $ARCH --api 19 --host gcc-lpthread -C \
using the maven_verify
commands in gitlab-ci.yml and opening up the resulting aar's and manually integrating them together. This seemed to work, but I also realized that running the following command produced an aar with all the libs supporting the min API I used above
python build.py -t android -a arm --keep-native-libs --docker nodejs j2v8cmake j2v8jni j2v8cpp j2v8optimize j2v8java j2v8test > arm.txt 2>&1 && cat arm.txt && ! grep -q BUILD\ FAILED arm.txt && echo passed
I lowered the min API to 16 and built again and confirmed that it worked on lower API levels down to API 16.
Thanks @kraizman, it worked! it was my mistake that I just unzip
and zip
to create aar
I think.
Here are steps:
-
Through gradle just sync/build your app with dependency
api 'com.eclipsesource.j2v8:j2v8:4.8.2@aar'
and again withapi 'com.eclipsesource.j2v8:j2v8:4.8.4@aar'
this will bring.aar
files in~/.gradle/caches/modules-2/files-2.1/com.eclipsesource.j2v8/j2v8/
-
Now
unzip
j2v8-4.8.2.aar
andj2v8-4.8.4.aar
file from child directory from~/.gradle/caches/modules-2/files-2.1/com.eclipsesource.j2v8/j2v8/
in separatej2v8-4.8.2
andj2v8-4.8.4
directory respectively -
Copy 32 bit
.so
files fromj2v8-4.8.2/jni/
and paste it inj2v8-4.8.4/jni/
-
Now create
.aar
with commandjar cvf j2v8-4.8.4.aar -C j2v8-4.8.4/ .
-
Use this newly created
j2v8-4.8.4.aar
in gradle instead ofapi 'com.eclipsesource.j2v8:j2v8:4.8.4@aar'
I have updated the 4.8-maintenance build to use API 16 for the 32 bit builds and 21 for the 64 bit builds. I've pushed a new SNAPSHOT as 4.8.5-SNAPSHOT
[1]. Can anybody test this and see if this works for 4.4 devices?
[1] https://oss.sonatype.org/content/repositories/snapshots/com/eclipsesource/j2v8/j2v8/4.8.5-SNAPSHOT/
Here is what I did. https://github.com/eclipsesource/J2V8/commit/b9b704f4b89f31248f357fae86d49164b19c1bea
Cool, I will test
I've done initial testing of arm down as low as API 19 (4.4) as well as 64bit on 9/10 and working so far
I can also confirm that the provided SNAPSHOT works on android 4.4.
Should be available in Maven Central as a real release now.
<dependency>
<groupId>com.eclipsesource.j2v8</groupId>
<artifactId>j2v8</artifactId>
<version>4.8.5</version>
<type>aar</type>
</dependency>
Thanks everyone! I imagine most people care about this for the 4.8 stream. I'm not sure if we should port this to 5.x too? What do we lose by using API 16 to build our 32 bit platforms, anything?
Thanks @irbull production release working in testing so far. Sounds reasonable to me to have 5.x up support to min 21 considering there is lower SDK level support in 4.8.x providing somewhat of a migration path.
Hi @irbull just downloaded the zip library from GitHub and included to Android Studio as a module but i am still getting the error:
cannot locate symbol "sigemptyset" referenced by "libj2v8.so"
Any suggestion?
That sounds like be a bad lib, are you not able to pull from maven repo?
Using
compile"com.eclipsesource.j2v8:j2v8:4.8.5@aar"
Doesn't work.