[osg-users] OSG and Android

[Jason Daly]

Hi, all,

I had a question about compiling OSG on Android. I understand that the
current advice is to build static libraries instead of shared. I was
just wondering why this was the case. Is there some reason that the OSG
can't be built with shared libraries instead?

The main reason I'm asking is that I'd prefer to avoid having to specify
the plugins in the code, and use the normal dynamic loading mechanism,
if possible.

--"J"
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Jorge Izquierdo Ciges]

Because the shared linker at execution time in Android works as hell on a bench. It just doesn't call the dependencies of a library... and also your shared libraries are not installed on the system... etc

The system is just not friendly to use shared libraries.

Can OSG be used as a shared library... if you modify it yourself yes. There are some crashes here and there but it's functional. But then you'll have to face all the other worryes of installing the shared libraries... where... for each application and create an ordered library opener. OpenCV had to create another program just to deploy it's own shared libraries.

P.S. Oh and I was forgetting that the shared linker on Android when a library has failed to load then it won't try load that library even if you want to force him until he's forgotten the library (mainly when you kill your process)

GoodLuck

2013/1/10 Jason Daly <jd...@ist.ucf.edu>

[Jason Daly]

On 01/10/2013 05:16 PM, Jorge Izquierdo Ciges wrote:
>
> Because the shared linker at execution time in Android works as hell
> on a bench. It just doesn't call the dependencies of a library... and
> also your shared libraries are not installed on the system... etc
>
> The system is just not friendly to use shared libraries.
>
> Can OSG be used as a shared library... if you modify it yourself yes.
> There are some crashes here and there but it's functional. But then
> you'll have to face all the other worryes of installing the shared
> libraries... where... for each application and create an ordered
> library opener. OpenCV had to create another program just to deploy
> it's own shared libraries.
>
> P.S. Oh and I was forgetting that the shared linker on Android when a
> library has failed to load then it won't try load that library even if
> you want to force him until he's forgotten the library (mainly when
> you kill your process)

OK, if that's all it is, I'm going to give it a shot.

After fighting a bit with the platform, we've had some luck with getting
other libraries working as shared libraries, so I think we'll be OK here.

It's compiling now and seems to be reasonably happy. Of course, as you
pointed out, compiling and linking is the easy part :-)

[Jan Ciger]

On 01/10/2013 11:49 PM, Jason Daly wrote:
> OK, if that's all it is, I'm going to give it a shot.
>
> After fighting a bit with the platform, we've had some luck with getting
> other libraries working as shared libraries, so I think we'll be OK here.
>
> It's compiling now and seems to be reasonably happy. Of course, as you
> pointed out, compiling and linking is the easy part :-)

I think you will have most problems with actually using plugins (unless
you keep them linked in statically). I don't think that there is a
documented interface how to load shared libs at runtime from C/C++ on
Android, you have to load the shared libs from within Java code.

If you compile all of OSG into one large shared lib and try to load that
at runtime instead of static linking, that should be possible without
too much hassle - e.g. Qualcomm's Vuforia/QCAR is doing it, OpenCV is
doing it, etc. Just make sure to set the lib up as "prebuilt", so that
it gets actually included in your APK and deployed on the device properly.

Regards,

Jan

[Jason Daly]

On 01/10/2013 06:32 PM, Jan Ciger wrote:
> On 01/10/2013 11:49 PM, Jason Daly wrote:
>> OK, if that's all it is, I'm going to give it a shot.
>>
>> After fighting a bit with the platform, we've had some luck with getting
>> other libraries working as shared libraries, so I think we'll be OK here.
>>
>> It's compiling now and seems to be reasonably happy. Of course, as you
>> pointed out, compiling and linking is the easy part :-)
> I think you will have most problems with actually using plugins (unless
> you keep them linked in statically). I don't think that there is a
> documented interface how to load shared libs at runtime from C/C++ on
> Android, you have to load the shared libs from within Java code.
>
> If you compile all of OSG into one large shared lib and try to load that
> at runtime instead of static linking, that should be possible without
> too much hassle - e.g. Qualcomm's Vuforia/QCAR is doing it, OpenCV is
> doing it, etc. Just make sure to set the lib up as "prebuilt", so that
> it gets actually included in your APK and deployed on the device properly.

Actually, we've got shared library loading working already.

A lot of our software is plugin-based (using dlopen), and it's working
fine on Android. There is a bit of JNI involved, but only enough to
hook into the regular Android GUI/View stuff.

--"J"

[Jan Ciger]

On Fri, Jan 11, 2013 at 1:28 AM, Jason Daly <jd...@ist.ucf.edu> wrote:

Actually, we've got shared library loading working already.

A lot of our software is plugin-based (using dlopen), and it's working fine on Android.  There is a bit of JNI involved, but only enough to hook into the regular Android GUI/View stuff.

Ah, that's good news then. Would you mind to publish any changes you needed to do to it? I would love to switch to shared lib too, because with the static linking the recompiles are taking ages every time.

Regards,

Jan

[Jason Daly]

I will if I can.  I doubt I'll be able to, though.  I'm frantically trying to finish this up before I switch jobs next week, and I've got a few other things on the plate, too.  My outside work time is pretty full too, with moving and stuff.

I'm currently doing things like writing the Android.mk file manually for our specific build tree, which is fine for the guys here, but probably wouldn't do for OSG in general.

If nothing else, I could give you what I end up with and you (or someone else) could massage it into a nice, CMake-friendly form if you like.

--"J"