NDK r10c dlopen failed: cannot locate symbol "atof" referenced

[Crossle Song]

When i use NDK r10b build success

APP_ABI := armeabi-v7a-hard
APP_PLATFORM := android-19

but when use NDK r10c, platform targe android-21, compile ok, but run error: dlopen failed: cannot locate symbol "atof" referenced

APP_ABI := armeabi-v7a-hard
APP_PLATFORM := android-21

[Alex]

I have exactly the same problem, except I'm missing "srand" function. I guess we're just getting the same errors in different order.

[Andrew Esh]

This seems like a basic library access problem, since those functions are defined in libc. Are you using a 64-bit platform? Did you add 32-bit support to it?

http://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit

Otherwise, could you post more specific information about the error you are encountering?

[Andrew Hsieh]

Some functions in stdlib.h (atof, srand, etc) used to be static inlined functions before android-21 and start to exist in libc.so from android-21.

It looks like your app is compiled with android-21 but run on pre-21 devices.  It may not work because app uses functions don't exist in previous device.

Please see b.android.com/77004

[Crossle Song]

I used NDK r10c compile 32bit library,compile ok, link ok, and run on my Android 4.4.4 phone, dlopen error.

[Crossle Song]

OOPS, What can i do? I wana use android-21 compile , and run pre-21 and 21+ devices.

[Andrew Hsieh]

This is quite dangerous. But if you insist, you need to find a device runs the oldest API level your app claims to support, and provide your own implementation of all missing functions like atof as reported by /system/bin/linker.

You can find how pre-21 device implement atof in pre-21 headers, and write "double atof(const char *nptr) { return (strtod(nptr, NULL)); }" in your code.

Again, doing this at your own risk.

[Crossle Song]

I dont think this a good solution, i use many open source c project, so badly use in NDK....

[Michael Moussa]

Did you try a soft float abi? Depending on your flags with hard float abi you may or may not have the math library included. The system math lib is soft float, so for hard float math you need to include your own. I use hard float within my lib, but linked against the system soft float....

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a-hard)

LOCAL_CFLAGS += -mhard-float

ifeq (,$(filter -fuse-ld=mcld,$(APP_LDFLAGS) $(LOCAL_LDFLAGS)))

LOCAL_LDFLAGS += -Wl,--no-warn-mismatch

endif

Some hard float examples have additional flags to disable system math library assuming you will link against your own hard float math library. So my only guess is you possibly copied an Android.mk with that in it. Could you post your entire Android.mk file?

[Crossle Song]

Application.mk

APP_CFLAGS += -marm -O3 -Wno-psabi -mhard-float -D_NDK_MATH_NO_SOFTFP=1 -fdiagnostics-color=always
APP_LDFLAGS += -lm_hard -Wl,--no-warn-mismatch

[Michael Moussa]

I believe   -D_NDK_MATH_NO_SOFTFP=1  is the problem. It tells the compiler not to link the system math lib, it assumes that you will build and link your own hard float compiled math library. The reason for this is that the OS only has soft float math lib, not a hard float. For my use case I was not using anything too computationally intensive from math, so I stuck with the system soft float math. If you do have a couple functions from math that you use that are used often that you would benefit from hard float, you could create those couple functions yourself and not use math at all.

Mike

[Crossle Song]

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "srand" referenced by

OOPS

[Michael Moussa]

Did you try -D_NDK_MATH_NO_SOFTFP=0 ???

[Michael S.]

Hi Andrew,

Are you saying that apps either run pre Android 5 (by using Android-19 as build target) or Android 5 and up (by using Android-21 as build target)?
Or am I misreading your reply?

If so, I'm guessing we're going to have to make 2 seperate apk's, 1 for android-19 and lower and 1 for android-21 (and higher).
That sounds like a horrible change, for developers as for customers, who will only get confused (unless the correct package is downloaded automatically).

[Michael S.]

To answer my own question, using build target Android 19 with NDK r10c works on Android 5 as well as earlier once.
Using Android 21 as build target will only work on Android 5, lower android versions will give the "cannot find symbol" error, due to those stdlib functions missing from the so.

I was using build target Android 21 purely because I read somewhere that you should always use the latest android build target for your app.
So as long as you don't need any functions introduced with Android 21, just stay on 19, and you should be fine.

Kind regards,
Michaël

[Crossle Song]

Thanks, still use Android 19 with NDK r10c.

[Dmitry Moskalchuk]

Another option would be to use CrystaX NDK 10: https://www.crystax.net/android/ndk/10

In CrystaX NDK, atof (as well as other math functions) is implemented in libcrystax and don't depend on libc version on device.

-- 
Dmitry Moskalchuk

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[Stanley Kurdziel]

I have encountered this same issue with NDK r10d and android-21 at runtime on both 4.4 and 5.0 devices: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "atof" referenced by "libExample.so"...

The workaround I'm using at the moment is to use NDK r10b.  I've also confirmed that android-19 and r10d avoid the error.

@Andrew Hsieh: b.android.com/77004 initially looked to be good additional information, but then I realized that aside from being a different error (not "atof") it's reported against NDK r10b.  NDK r10b *is working* for me, so I think 77004 is a distinct problem.

@Michael Moussa: -D_NDK_MATH_NO_SOFTFP=0 didn't make any difference for me

@Dmitry Moskalchuk  CrystaX NDK 10.1.0 also avoids the "atof" error. I will keep it in mind as a potential NDK replacement.  Does it track particular versions of the Android NDK?

[Dmitry Moskalchuk]

On 06/02/15 22:52, Stanley Kurdziel wrote:

@Dmitry Moskalchuk  CrystaX NDK 10.1.0 also avoids the "atof" error. I will keep it in mind as a potential NDK replacement.  Does it track particular versions of the Android NDK?

CrystaX NDK is synchronized with Google's NDK sources every week or two, so it always in sync with Google's Android NDK, even though it doesn't track specific version (instead, we're using rolling git HEAD synchronization).


--
Dmitry Moskalchuk

[Rafael Ferraz]

I'm having this problem with srand() using target 23 when running on kiit kat devices, didnt test on higher devices tho. My ndk version is the latest : 12. What I did was lower the target sdk to 19. 

[Dan Albert]

using target 23 when running on kiit kat devices

You can't do that. The "target" API level for the NDK is not the same as in Java. It's the minimum API level you want to run on.

On Tue, Jun 7, 2016 at 2:08 PM, Rafael Ferraz <rafae...@gmail.com> wrote:

I'm having this problem with srand() using target 23 when running on kiit kat devices, didnt test on higher devices tho. My ndk version is the latest : 12. What I did was lower the target sdk to 19. 

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, 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/ca85bf98-1bc5-450d-8056-57dc57ad6dc8%40googlegroups.com.