GNU bug report logs -
#66508
30.0.50; Emacs Android port crashes due to link error when build with libxml2 and ImageMagick7
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
After building and installing Emacs Android port with libxml2 and
ImageMagick, Emacs crashed during startup with such bellow error on logcat
output.
10-13 06:00:10.489 22999 22999 I SELinux : SELinux: seapp_context_lookup:
seinfo=untrusted, level=s0:c512,c768, pkgname=org.gnu.emacs
10-13 06:00:10.873 22999 22999 W linker :
"/data/app/org.gnu.emacs-qyrcKpWJ8LCBp8R1gwRLIg==/lib/arm64/libc++_shared.so"
unused DT entry: type 0x70000001 arg 0x0
10-13 06:00:10.888 22999 22999 W linker :
"/data/app/org.gnu.emacs-qyrcKpWJ8LCBp8R1gwRLIg==/lib/arm64/libc++_shared.so"
unused DT entry: type 0x70000001 arg 0x0
10-13 06:00:11.005 22999 22999 E AndroidRuntime: Process: org.gnu.emacs,
PID: 22999
10-13 06:00:11.005 22999 22999 E AndroidRuntime:
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol
"UCNV_TO_U_CALLBACK_STOP_64" referenced by
"/data/app/org.gnu.emacs-qyrcKpWJ8LCBp8R1gwRLIg==/lib/arm64/libxml2_emacs.so"...
10-13 06:00:11.005 22999 22999 E AndroidRuntime: at
org.gnu.emacs.EmacsNative.<clinit>(EmacsNative.java:322)
10-13 06:00:11.005 22999 22999 E AndroidRuntime: at
org.gnu.emacs.EmacsNative.setupSystemThread(Native Method)
10-13 06:00:11.005 22999 22999 E AndroidRuntime: at
org.gnu.emacs.EmacsApplication.onCreate(EmacsApplication.java:84)
And below are nm out put,
this one is when build with libxml2 only,
nm arm64-v8a/libxml2_emacs.so |grep -i ucnv
U UCNV_FROM_U_CALLBACK_STOP_56
U UCNV_TO_U_CALLBACK_STOP_56
U ucnv_close_56
U ucnv_convertEx_56
U ucnv_open_56
U ucnv_setFromUCallBack_56
U ucnv_setToUCallBack_56
and below is when build with libxml2 and ImageMagick7
nm arm64-v8a/libxml2_emacs.so |grep -i ucnv
U UCNV_FROM_U_CALLBACK_STOP_64
U UCNV_TO_U_CALLBACK_STOP_64
U ucnv_close_64
U ucnv_convertEx_64
U ucnv_open_64
U ucnv_setFromUCallBack_64
U ucnv_setToUCallBack_64
I think this is caused by a conflict due to static libraries *.a having
the same name during build.
(not *.o because they are made unique by prefixing path to *.o.)
Thanks,
[Message part 2 (text/html, inline)]
This bug report was last modified 1 year and 161 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.