The cause of the dependency on libgnustl_shared.so is twofold.
First, any code that uses the standard C++ library will need this. That
includes some of the code in plugin opcodes, notably the Lua opcodes and the
signal flow graph opcodes. Second, there are static elements in C++ code that
require that, if a process loads more than one C++ module, all the C++ modules
need to be in shared libraries, otherwise data may be corrupted or the app may
even crash.
My whole motive for working on Android Csound is to be able to compose on
my phone, and to do that I need the Lua opcodes and the signal flow graph
opcodes. I've noticed a number of other composers also use the signal flow
graph opcodes, so I think there are good reasons for trying to get this to
work.
So I don't consider dropping these opcodes to be an option.
We do have options however:
First, we can just get this to work. This is my preference. However, I've
done a fair amount of research and as far as I can tell I am doing everything
correctly now.
Second, we can statically link the app and all the "plugins" into one
app, except for LuaJIT, which has no dependency on any C++ code. This will
involve putting a little bit of code in the Android Csound C code to get these
opcodes into the opcode dispatch table using the Csound API. I will do this if
we can't get the gnustl thing resolved quickly.
Third, of course we can produce two versions of the app, one with the C++
plugins and one without. I noticed in the logs provided that libsndfile loaded
without any problems so I expect any other plain C plugins also will load
without any problems.
What do you think?
I'd appreciate more reports. Has anybody actually been able to run this
thing besides me?
Regards,
Mike