Android OpenAL library missing symbol 'strtof'

About Monkey 2 Forums Monkey 2 Programming Help Android OpenAL library missing symbol 'strtof'

This topic contains 6 replies, has 2 voices, and was last updated by  Mark Sibly 2 years, 6 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #4405

    arpie
    Participant

    Is this the best/right place to be bringing up Android related issues?  If not, please point me to a better place.

    I have built helloworld.monkey2, and two bananas: sdl2test and simplelight.  All three run flawlessly on my Sony Xperia running Android 6.0.1 (and simplelight looks amazing!  Can’t wait to start writing some real games…).

    On the other hand, there is a missing symbol being reported on my Lenovo Yoga tablet (running Android 4.4.2, API version 19).  The precise error reported when I try to launch an app is :

    I have not a scooby where it expects to find the ‘strtof’ symbol?  Isn’t it a stdlib function?  How can it be missing?

    [ To clarify, the sdl2test banana suffers from a different but related error – it doesn’t add the libopenal.so file to the project at all.  This can be fixed by adding ‘#import “<mojo>”‘ to the monkey2 file.  Should it be automatically added to the Android project even without mojo being imported?  Still getting the missing strtof symbol error, though. ]

    I tried setting the Gradle target API to 19 but still get the same error.

    Any suggestions?

    #4406

    arpie
    Participant

    I’ve done some deeper searching and it seems to be the case that Google decided to move strtof (and other similar functions such as atof) from the app-bundled NDK libraries into the standard Android libraries installed on later devices, or something to that effect.  The upshot is that if you build an app with later versions of NDK where the strtof symbol is expected to already be on the device, but run the app on an old device… the symbol is missing.

    How to solve it?  There seem to be two options.

    – Use an earlier NDK library to build the app (10d is suggested to work – I am currently downloading it and will try it tomorrow).

    – Use a non-google alternative NDK library such as Crystax NDK (https://www.crystax.net/)

    This thread has a more detailed discussion of a similar issue :

    http://android.2317887.n4.nabble.com/NDK-r10c-dlopen-failed-cannot-locate-symbol-quot-atof-quot-referenced-td266165.html

    Does anybody here have any experience with the CrystaX NDK library?  Is it something to be recommended that Mark adopt for Monkey?  I had never even heard of it until today.

    #4409

    Mark Sibly
    Keymaster

    Woah, somone’s actually *using* the android target?!?

    Double woah, lightsparks works really nicely on my Shield! And, once I remembered to build modules, it’s a pretty smooth build/run process.

    As for the strof issue, according to both the thread you linked to above and this thread here:

    http://stackoverflow.com/questions/14571399/android-ndk-cant-find-atof-function

    …it should be enough to set APP_PLATFORM in Application.mk for the openal.so project to an api version <=19.

    The project that builds openal.so isn’t actually included in the mx2 repos (it’s here: https://github.com/apportable/openal-soft.git) but looking at it now, APP_PLATFORM isn’t set to *anything* in Application.mk. And I’m getting a warning when building about api 24 being greater than minsdk version, so it’s probably using api 24.

    I’ll rebuild openal.so using api 10 (which is the what the mx2 product minsdk is) and upload soon.

    #4424

    Mark Sibly
    Keymaster

    New build of openal.so is up now.

    #4443

    Mark Sibly
    Keymaster

    …does it work?

    #4462

    arpie
    Participant

    Woah, somone’s actually *using* the android target?!?

    Isn’t that why you made it?  Am I the only one?

    New build of openal.so is up now.  …does it work?

    I thought no, then I tried again and it looks like yes.  Android Studio is the most unintuitive piece of cr#p software I’ve ever seen and it seems to intentionally screw up its own automaticly generated Gradle configuration files just for fun, in a different way every time I run it.

    But basically, I think it is working.

    Have I understood correctly that it was only openal.so that needed the targetSdkVersion etc. set to 19 and I can use a later version number (currently 24) to build my project?  That is what I think I’ve done with lightsparks and it is now happily running on my Android 4.4.2 tablet.

    In case it is of any interest, I also tried rebuilding all modules using CrystaX NDK.  It adds an extra library to the project (libcrystax.so), and also works perfectly on all my devices.  It claims a number of advantages over the Google NDK : it allows Boost libraries to be used, provides better locale support and wide character support, and apparently irons out all differences between different Android versions… see https://www.crystax.net/en/android/ndk for a more indepth comparison (it will probably be more meaningful to you than to me!).  The .so file weighs in at only 574k here, which seems pretty lightweight to me considering all its advantages. (Just to be clear; I have no affiliation of any sort with the CrystaX project and had never heard of it until a few days ago)

    Anyway, thanks for your help again.  Sorry this reply was slow coming.

    #4463

    Mark Sibly
    Keymaster

    I thought no, then I tried again and it looks like yes.

    Yay!

    Have you disabled this?

    File->Settings->Build, Execution, Deployment->Instant Run->Enable Instant Run

    This solved a lot of weird gradle-related problems I was having. Another tip: always close a project before you open a new one!

    As for Android Studio, yep, it’s a bit rough around the edges, esp. when compared to xcode!

    > Have I understood correctly that it was only openal.so that needed the targetSdkVersion etc. set to 19 and I can use a later version number (currently 24) to build my project?

    Yes. Each blah.so is really it’s own self contained thing.

    In case it is of any interest, I also tried rebuilding all modules using CrystaX NDK.

    This sounds pretty cool and I might look into later, but right now I’m sticking with the plain NDK.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.