lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 12/25/16, Marc Balmer <> wrote:
> Am 25.12.16 um 20:02 schrieb Thomas Fletcher:
>> On Dec 25, 2016 7:02 AM, "Marc Balmer" <
>> <>> wrote:
>>> I am late to the game, but I recently started working on an Android app
>>> that includes Lua.  Fortunately I have quite a bit of experience with
>>> the JNI and several (non Android) projects where Lua is called from
>> Java...
>>> Now I wonder how other Android/Lua hackers handle 'require' for modules
>>> written in C/C++.  Do you link your modules with Lua into a single
>>> library or do you create several .so files?  If the latter, how do you
>>> trick Lua into loading the right shared object?
>> With Storyboard we give the user the ability to list their binary
>> modules and then preload them in the main android application by
>> dlopening the files so that later when we retry within a secondary or
>> tertiary module it succeeds.
> Thanks so far.  So I am now able to detect the CPU architecture and ABI
> using C preprocessor defines and in theory I can now adjust the
> LUA_CPATH_DEFAULT definition in luaconf.h.  But is the APK file actually
> unpacked on the Android device's file system?  I.e. can I just adjust
> the CPATH and then use dlopen() to load the module?  Or do I have unzip
> the APK first?
> I was also considering writing a separate loader that calls
> System.loadLibrary() via the JNI, but then that assumes as "lib" prefix
> on the shared library, which we omit for Lua modules (we often have a C
> library called e.g. _and_ a Lua binding to it called

I try to preserve the usual Lua semantics for Android which means
building dynamic libraries. So as you identified, I always use the lib
prefex on Android. But this isn't just for System.loadLibrary(), but
affects what Android does when it encounters your .apk. Android
automatically extracts out the lib*.so files into a special directory
so it is possible to use them. It ignores everything else. CPATH alone
wouldn't help you since the files are not directly on the filesystem,
but archived inside the APK.

I had a slide about this in my talk, "Tales of a Lua engine embedder
thrown into the JavaScript world" at the Lua Workshop 2016. It's
around slide #34 at about the 10 minute mark.

I use this for BlurrrSDK. I also made changes to make normal Lua
semantics work on iOS with its static linking. (Mentioned in the
following slide.)