dlopen failed: cannot locate symbol "mmap64" and unexpected e_machine

[Davy Wentzler]

I am trying to compile the latest FFmpeg using the latest NDK r20 and although it works on arm64-v8a (which actually was part of the goal since I am trying to comply with the upcoming 64-bit requirement), I have less luck on x86 and armeabi devices.

Please note that compilation and creation of the 4 FFmpeg shared objects proceeds without errors and I don't need the FFmpeg executable, just the libs. I compile on a Linux virtual machine.

First, when I build for armeabi-v7a and arm64-v8a and run it on a Dell Venue Intel tablet with Android 4.4.2, I get this error:

fatal error : dlopen failed: "/data/app-lib/com.extreamsd.usbaudioplayerpro-1/libavutil.so" has unexpected e_machine: 40

on the call to System.loadLibrary("avutil") of the ffmpeg libraries. So the emulator is not liking the flavour I built, although it's armeabi-v7a without extra's like NEON. The libraries that I built with ndk-build that are loaded before that with System.loadLibrary() are loaded fine.

So, no worries, let's build for x86 as well now we are at it! But then I get:

com.extreamsd.usbaudioplayerpro fatal error : dlopen failed: cannot locate symbol "mmap64" referenced by "libavutil.so

Then to check the 32-bit build, I ran the armeabi-v7a build on a Nexus 5 (which doesn't feature 64-bit) and I get:

dlopen failed: cannot locate symbol "__aeabi_memcpy" referenced by "/data/app/com.extreamsd.usbaudioplayerpro-1/lib/arm/libavutil.so".

when I reduce the NDK platform level from 26 to 22 or so, this error disappears (although this 'trick' does not work on the Intel problem above).

Running the arm64-v8a build on a 64-bit Android device is fine.

With a built of ffmpeg that I built two years ago or so (armeabi-v7a only) with gcc, things run fine, but I cannot use that anymore.

Any pointers?

[Ryan Prichard]

On Thu, Jun 20, 2019 at 7:49 AM Davy Wentzler <extr...@gmail.com> wrote:

I am trying to compile the latest FFmpeg using the latest NDK r20 and although it works on arm64-v8a (which actually was part of the goal since I am trying to comply with the upcoming 64-bit requirement), I have less luck on x86 and armeabi devices.

Please note that compilation and creation of the 4 FFmpeg shared objects proceeds without errors and I don't need the FFmpeg executable, just the libs. I compile on a Linux virtual machine.

First, when I build for armeabi-v7a and arm64-v8a and run it on a Dell Venue Intel tablet with Android 4.4.2, I get this error:

fatal error : dlopen failed: "/data/app-lib/com.extreamsd.usbaudioplayerpro-1/libavutil.so" has unexpected e_machine: 40

on the call to System.loadLibrary("avutil") of the ffmpeg libraries. So the emulator is not liking the flavour I built, although it's armeabi-v7a without extra's like NEON. The libraries that I built with ndk-build that are loaded before that with System.loadLibrary() are loaded fine.

So, no worries, let's build for x86 as well now we are at it! But then I get:

com.extreamsd.usbaudioplayerpro fatal error : dlopen failed: cannot locate symbol "mmap64" referenced by "libavutil.so

Then to check the 32-bit build, I ran the armeabi-v7a build on a Nexus 5 (which doesn't feature 64-bit) and I get:

dlopen failed: cannot locate symbol "__aeabi_memcpy" referenced by "/data/app/com.extreamsd.usbaudioplayerpro-1/lib/arm/libavutil.so".

libc.so should have __aeabi_memcpy, but starting in API 24, the symbol is marked with a LIBC_N version tag: "__aeabi_memcpy" -> "__aeabi_memcpy@@LIBC_N". Maybe your libavutil.so shared library is using a LIBC_N version tag on a pre-N device. Running "readelf --dyn-syms -W" on libavutil.so will show the symbols and version tags that the library is using.

 

when I reduce the NDK platform level from 26 to 22 or so, this error disappears (although this 'trick' does not work on the Intel problem above).

The NDK's target API setting is the minimum API the shared library can run on. I suspect that explains the mmap64 and __aeabi_memcpy problems. mmap64 was added to libc.so in API 21. For older Android versions, the NDK has a legacy inline mmap64 function that calls __mmap2.

https://android.googlesource.com/platform/bionic/+/2356c93d391c1948b3abb7602da3d97bd8b289f2/libc/libc.map.txt#668

https://android.googlesource.com/platform/bionic/+/2356c93d391c1948b3abb7602da3d97bd8b289f2/libc/include/android/legacy_sys_mman_inlines.h

-Ryan

 

[Davy Wentzler]

Hi Ryan,

First of all, thanks for helping me out!

So, with armeabi-v7a back to target API 16, it rus on the Nexus 5 (with Android 6.0). It still does not run with armeabi-v7a emulated on the Dell due to the unexpected e_machine: 40, but I can live with that as long as the x86 build runs. I set the target API to 16 for the x86 build and it still complains:

com.extreamsd.usbaudioplayerpro fatal error : dlopen failed: cannot locate symbol "mmap64" referenced by "libavutil.so"

The readelf command on the armeabi-v7a libavutil.so gives

FUNC GLOBAL DEFAULT UND __mmap2@LIBC (2)

(but runs)

and readelf on the x86 so gives:

NOTYPE GLOBAL DEFAULT UND mmap64

Kind regards,

Davy

eXtream Software Development

--
You received this message because you are subscribed to a topic in the Google Groups "android-ndk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-ndk/t_cTNnhSlXE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CALgsJznKtZ_4FUW7oCjVfB3FHToC_A8cZ_-GrQZron%2BikTK0og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Davy Wentzler]

Ah, _FILE_OFFSET_BITS=64 was turned on in configure. Removing that solves that problem, but brings:

dlopen failed: cannot locate symbol "stderr" referenced by "libavutil.so"

That seems to be the only 'UND' without @LIBC in readelf left.

Kind regards,

Davy

eXtream Software Development

[Davy Wentzler]

Assuming this is a STL problem, in my Application.mk I have c++_shared since I use multiple .so's. In the ffmpeg build, I didn't define anything but I read somewhere that it defaults to c++_shared, which is perhaps not true?

Kind regards,

Davy

eXtream Software Development

[Davy Wentzler]

Replying to myself again. Turns out that the original build script used

CC_FLAGS = "-target i686-none-linux-androideabi"

when I change that to

CC_FLAGS = "-target i686-none-linux-android16"

then the stderr is gone.

So key part is to put ndk-build in verbose mode and look closely on which commands it uses and put that in the cross-compile build script. The e_machine error is still odd, but I can live with it.

To unsubscribe from this group and all its topics, send an email to android-ndk+unsubscribe@googlegroups.com.