Problem when building gideros plugin

kujira

I'm learning to create gideros plugins using "Creating plugins for Android in Gideros" tutorial.

I'm not familiar with c++ building etc. After hours of trials and errors I figured out that I can build normally for armeabi and armeabi-v7a, but fail to build for x86.

[x86] Compile++ : exampleplugin <= exampleplugin.cpp
[x86] Prebuilt : libgideros.so <= jni/../../libs/armeabi/
[x86] SharedLibrary : libexampleplugin.so
/Applications/ndk/toolchains/x86-4.6/prebuilt/darwin-x86_64/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/bin/ld: error: ./obj/local/x86/libgideros.so: incompatible target
/Applications/ndk/toolchains/x86-4.6/prebuilt/darwin-x86_64/bin/../lib/gcc/i686-linux-android/4.6/../../../../i686-linux-android/bin/ld: ./obj/local/x86/objs/exampleplugin/exampleplugin.o: in function luaopen_plugin(lua_State*):jni/exampleplugin.cpp:40: error: undefined reference to 'luaL_register'

... and much more lines

So the ndk builder can't work with gideros x86 library?
How can I solve this problem? Thanks!

ar2rsawseen

Interesting, never had a problem with building x86, and never did anything more than adding

APP_ABI := armeabi armeabi-v7a x86

to Application.mk

It seems that you simply don't have or have incorrect gideros x86 binaries

kujira

I've mixed up all libraries. I can't build armeabi and armeabi-7va too using the libraries from my exported gideros project. But I can build with libraries that I get from the example project from the tutorial.

So I've come to a wrong conclusion that I can't build for x86. I couldn't build for x86 and was able to build for arme and arme7va, because I used a mix of old libraries from the example projects (that doesn't contain libraries for x86) and new libraries from my own gideros project (only x86 libs).

With old libraries I can build both the example project and my own gideros project, but with new - neither of them.

So what am I doing wrong? Is it ok to build with old libraries (sept 2012)? And what should I do to be able to build for x86? I've reinstalled gideros studio and ndk, but that didn't help.

ar2rsawseen

@kujira well that explains it.
To build plugins to new Gideros, you need to change your Android.mk file a bit.

Basically the changes are that there are now more binaries to linked
And of course you must be linking to new binaries and new header files from new Gideros SDK in all the provided paths.
Something like this should work now (changing to your own paths of course)

LOCAL_PATH := $(call my-dir)   # # Gideros Shared Library #   ###   include $(CLEAR_VARS)   LOCAL_MODULE := lua LOCAL_SRC_FILES := ../../libs/$(TARGET_ARCH_ABI)/liblua.so   include $(PREBUILT_SHARED_LIBRARY)   ###   include $(CLEAR_VARS)   LOCAL_MODULE := gideros LOCAL_SRC_FILES := ../../libs/$(TARGET_ARCH_ABI)/libgideros.so   include $(PREBUILT_SHARED_LIBRARY)   ###   include $(CLEAR_VARS)   LOCAL_MODULE := gvfs LOCAL_SRC_FILES := ../../libs/$(TARGET_ARCH_ABI)/libgvfs.so   include $(PREBUILT_SHARED_LIBRARY)   ###   include $(CLEAR_VARS)   LOCAL_MODULE := zlib LOCAL_SRC_FILES := ../../libs/$(TARGET_ARCH_ABI)/libzlib.so   include $(PREBUILT_SHARED_LIBRARY)   # # Plugins #   ###   include $(CLEAR_VARS)   LOCAL_MODULE := exampleplugin LOCAL_ARM_MODE := arm LOCAL_CFLAGS := -O2 LOCAL_C_INCLUDES += $(LOCAL_PATH)/../../libs/include LOCAL_SRC_FILES := exampleplugin.cpp LOCAL_LDLIBS := -ldl -llog LOCAL_SHARED_LIBRARIES := lua gideros   include $(BUILD_SHARED_LIBRARY)

kujira

Now it works. Thank you!

Nascode

Building .so for Android is a major pain - if you ask me. With iOS, we just copy paste c files since everything is native. Crossing bridge between LUA - C - Java via JNI is prone of error and full of dark magical thing

Oh and if you dont target ARMv6, just remove APP_ABI for armeabi - ARMv7 is majority right now

tkhnoman

Hmm...
I never really did building any .so files

All what i do is change any existing plugin at Gideros,
for example ads-interface, there is "getWidth()" which i never used, i then overwrite that one for any thing that i want, for example to get battery status.
And for naming, i override that at lua (to make sure i remember it right) :

function getBatteryStatus()
return admob:getWidth()
end


Also, if i want some thing like dispatch event, i then change AdsError() which somehow never really fired anyway.


Probably this is weird, but i find out that it works and super easy, so yeah...
And i did this also for iOS.
)

ar2rsawseen

) that is an awesome hack

Maybe need to create some generic dummy plugin with lots of functions and events, just so it could be used that way

OZApps

if you are thinking seriously, then you could have many functions with just one API call and a parameter or even more with two parameters. You could use something like

function genericObj:OverriddenFunction(parameter1) if parameter1 == "Battery" then -- return the battery status elseif parameter1 == "Memory" then -- return the memory status elseif parameter1 == "Music" then -- Play some music end end

this would then become like a APIPlug-in so as to speak, the hack that tkhnoman mentioned was using existing libraries and using their functions hoping that it doesn't break in the next release.

tkhnoman

That makes me remember, i have something like

admob:showAd("twitter")

People who see this would goes 'What!?'
)

OZApps

worst form of mangling functions would be

iOS:showUI("Android")

but then with Yosemite looking like Ubuntu or Fedora (a unix distro, specially with the icons and text) that would hardly be funny or mangling, it might actually be a serious API.

Nascode

Hey, actually this is a good idea !
@tkhnoman @ar2rsawseen

Generic plugin so we could avoid building .so :P

keszegh

if there is a solution when building so is not needed, that would be great.
at every new version i spend 1-2 hours while i manage to set up and build correctly my plugin.
also, if i've built an so, if a new version comes isn't it enough to just copy this .so and the java file in the src (with the plugin binding)? i never tried this, wouldn't this work?

Nascode

@keszegh from my knowledge, yes - just copy the .so files, except gideros.so changed or some groundbreaking changes happen

keszegh

sounds promising, i will try it with my next update.