It is a pretty nifty mechanism - it saves the huge linking times, because the
OpenCV is linked dynamically, you don't need to redistribute the OpenCV binary
with your app, it gets downloaded and updated automatically and you don't need
to try to figure out the path where to load the libraries
Hello Philip,
On 11/22/2012 11:56 PM, Philip Lamb wrote:
Yes, since we (ARToolworks) use OSG in our ARToolKit SDKs (across
Windows, OS X, Linux, iOS and hopefully soon, Android :-) ), we have
to anticipate that the users of our SDK will potentially run on any
architecture supported by Android.
I think Matthias is totally right. Android NDK toolchain doesn't use strip
when generating static libraries (it's not safe for all the cases). Usually
when you are compiling the final dylib that is loaded through Java the
toolchan uses stripping to reduze the size. but i think that it is only
used
Thanks everyone for the help. I have identified two things. The first was a
blunder on my part; I was looking at my linked dylib in obj/local, which
includes all the debug symbols. The ndk-build 'Install' step actually strips
the shared lib before placing it in lib/, and this was a much more
Hello,
On Thu, Nov 22, 2012 at 9:12 AM, Jorge Izquierdo Ciges jori...@gmail.comwrote:
I think Matthias is totally right. Android NDK toolchain doesn't use strip
when generating static libraries (it's not safe for all the cases). Usually
when you are compiling the final dylib that is loaded
Hello,
On Thu, Nov 22, 2012 at 10:48 AM, Philip Lamb p...@eden.net.nz wrote:
The second thing I did was add:
LOCAL_CPPFLAGS += -fvisibility-hidden
Careful about this - visibility could break things if the shared libraries
are not properly exporting symbols. In Linux it is quite common to
Jan - if you have set your own compile configuration you didn't include
that step.
Which means if you bypass the ndk-build scripts and use directly the gcc
you, yourself. :P
2012/11/22 Jan Ciger jan.ci...@gmail.com
e are *always* stripped, no matter what you do. Even when you are
compiling
On Thu, Nov 22, 2012 at 12:07 PM, Jorge Izquierdo Ciges
jori...@gmail.comwrote:
Jan - if you have set your own compile configuration you didn't include
that step.
Which means if you bypass the ndk-build scripts and use directly the gcc
you, yourself. :P
Well, he talked about Android.mk,
On 22/11/2012, at 11:44 PM, Jan Ciger jan.ci...@gmail.com wrote:
Do you actually need to compile for MIPS and x86? x86 Android devices are
very very rare and I have never heard about a MIPS one (maybe some TVs?). The
armeabi and armeabi-v7a are the most common ones, in fact, if you want to
Truth is that it is more or less that way. Still your dylib seems a little
bit huge to me, my usual examples and code with OSG stay in a 12-15-17 mark
depending on plugins and 3rd party... 170 i think is too much... The static
with 1Gb that's unavoidable and the reason why my pc is suffering a lot
Hello,
Well, one thing to do would be to change from static linking to linking OSG
dynamically. The OpenCV project does this using their OpenCV Manager app.
The main Activity in Android calls an asynchronous init that connects with
the manager. That manager downloads (if required) the proper
Did you try to strip your generated binary?
The command is just:
Code:
strip programfile
in the commandline.
If you're building dynamic you might strip the generated libs too. I'm not sure
if you can still dynamically link against stripped dynamic libs though. So keep
the original lib
12 matches
Mail list logo
