Building Ogre dependencies using NDK
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Building Ogre dependencies using NDK
I have managed to build the dependencies except for Freeimage.
Has anyone recently been able to build a .a static library using the current NDK 10e I think it is?
Has anyone recently been able to build a .a static library using the current NDK 10e I think it is?
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
Yes, I build ogredeps as part of my framework and I'm 99% sure my laptop is using 10e. You are building from the ogredeps repo?
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: Building Ogre dependencies using NDK
Yes but I had to patch freeImage - can you show me the compiler error I am not sure if I pushed it
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
Well it's a bit of a long story but yes I did get the source from the Ogredeps. I have since got various other attemps from the net with people building Freeimage.
The ogredeps library gives this error: when linked into my project.
I would prefer to build it using NDK but currently I am getting various errors:
I have found some repos with freeimage that did build with NDK but they seem outdated because even if I follow the steps it doesn't build.
The ideal thing would be a repo that would build with : ndk-build using ndk r10e.
The ogredeps library gives this error:
Code: Select all
error: undefined reference to '__srget'
I would prefer to build it using NDK but currently I am getting various errors:
Code: Select all
[armeabi] Compile++ thumb: FreeImage <= IlmThreadSemaphorePosix.cpp
jni/Source/OpenEXR/IlmThread/IlmThreadMutexWin32.cpp: In constructor 'IlmThread::Mutex::Mutex()':
jni/Source/OpenEXR/IlmThread/IlmThreadMutexWin32.cpp:49:5: error: '::InitializeCriticalSection' has not been declared
::InitializeCriticalSection (&_mutex);
^
jni/Source/OpenEXR/IlmThread/IlmThreadMutexWin32.cpp:49:35: error: '_mutex' was not declared in this scope
::InitializeCriticalSection (&_mutex);
The ideal thing would be a repo that would build with : ndk-build using ndk r10e.
Last edited by Slicky on Tue Feb 02, 2016 2:29 pm, edited 1 time in total.
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
Just to reiterate ideally I am not looking to do a cmake setup and then build using Visual Studio. I am trying to just use the command line: ndk-build
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
And trying a different build using Freeimage 3.17
Code: Select all
ndk-build -j 2
[armeabi] Compile++ thumb: FreeImage <= ImfHuf.cpp
[armeabi] Compile++ thumb: FreeImage <= ImfInputFile.cpp
In file included from jni/Source/OpenEXR/./IlmImf/ImfHuf.cpp:50:0:
jni/Source/OpenEXR/IlmImf/ImfAutoArray.h: In instantiation of 'Imf::AutoArray<T, size>::AutoArray() [with T = int; int size = 65537]':
jni/Source/OpenEXR/./IlmImf/ImfHuf.cpp:298:34: required from here
jni/Source/OpenEXR/IlmImf/ImfAutoArray.h:60:71: error: 'memset' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
AutoArray (): _data (new T [size]) { memset(_data, 0, size*sizeof(T)); }
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
To avoid confusion I just downloaded the Cabalastic repo and used that source. I can paste my android.mk and application.mk if that would be useful.
Here is the error from this fresh download:
Here is the error from this fresh download:
Code: Select all
[armeabi] Compile++ thumb: FreeImage <= IlmThreadPool.cpp
jni/Source/OpenEXR/IlmThread/IlmThreadMutexWin32.cpp: In constructor 'IlmThread::Mutex::Mutex()':
jni/Source/OpenEXR/IlmThread/IlmThreadMutexWin32.cpp:49:5: error: '::InitializeCriticalSection' has not been declared
::InitializeCriticalSection (&_mutex);
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
You should be using the ogredeps repo .... you should be following the steps outlined here:
http://www.ogre3d.org/tikiwiki/CMake+Qu ... on=Android
You can literally cut/paste step the command from step 3 to build ogredeps. Just change the CMake generator to "NMake Makefiles" in windows. Build from visual studio command prompt using nmake. Profit. If you want to use ndk-build you are on your own ... I use CMake to cross compile everything.
I double checked. My laptop is using 10e / vs2015 and ogredeps builds fine.
http://www.ogre3d.org/tikiwiki/CMake+Qu ... on=Android
You can literally cut/paste step the command from step 3 to build ogredeps. Just change the CMake generator to "NMake Makefiles" in windows. Build from visual studio command prompt using nmake. Profit. If you want to use ndk-build you are on your own ... I use CMake to cross compile everything.
I double checked. My laptop is using 10e / vs2015 and ogredeps builds fine.
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: Building Ogre dependencies using NDK
ah shit openEXR should be disabled - nobody needing it (I thought I disabled inside the deps)
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
That part built for me actually, but yeah I guess it would speed up compilation hahaWolfmanfx wrote:ah shit openEXR should be disabled - nobody needing it (I thought I disabled inside the deps)
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: Building Ogre dependencies using NDK
Yeah but I disabled a few codec to save memory freeimage just get that huge because of all supported codecs (and some like openEXR is not needed by the masses)
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
An update. Yesterday I got it to build using NDK except I removed tiff support because I was getting errors in the tiff code. Not the prettiest but for now it works. I may revisit the tiff part.
Using cmake on Windows do you get .a libraries? I'm still trying to understand it seems that using a standard windows. lib might not work?
All my supporting libraries including Ogre are .a
Using cmake on Windows do you get .a libraries? I'm still trying to understand it seems that using a standard windows. lib might not work?
All my supporting libraries including Ogre are .a
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
That's weird. The tiff code in freeimage builds for me.
In windows you get .a libs. When you build ogre and ogredeps on windows using the NDK, you are actually cross-compiling with gcc in a win32 exe form. The toolchain file you pass to CMake finds the cross compiler for you, and then nmake is actually compiling using gcc, so the resulting binary is .a for static and .so for dynamic
The way I have my own project set up is that all my dependencies are built as external projects using CMake, and then only my final application is built as an android project, linking against the other static libs, building using ndk-build and producing the final .so which is loaded by the small amount of java required to glue a native program into the android lifecycle using JNI
In windows you get .a libs. When you build ogre and ogredeps on windows using the NDK, you are actually cross-compiling with gcc in a win32 exe form. The toolchain file you pass to CMake finds the cross compiler for you, and then nmake is actually compiling using gcc, so the resulting binary is .a for static and .so for dynamic
The way I have my own project set up is that all my dependencies are built as external projects using CMake, and then only my final application is built as an android project, linking against the other static libs, building using ndk-build and producing the final .so which is loaded by the small amount of java required to glue a native program into the android lifecycle using JNI
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
Good info. Out of curiosity can you link a Windows .Lib into an android project. I'm thinking you can't for similar reasons on Windows linking for example debug and release.
My main reason for NDK is that once it is set up it is easy to build all types: arm x86 etc. I'm sure the same can be said of the cmake route but for me it seemed cleaner.
All of the other dependencies built with only minor issues. I read that zlib is already in the NDK but that was after I built it.
My main reason for NDK is that once it is set up it is easy to build all types: arm x86 etc. I'm sure the same can be said of the cmake route but for me it seemed cleaner.
All of the other dependencies built with only minor issues. I read that zlib is already in the NDK but that was after I built it.
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
ndk-build is just building it as many times as it takes, using different target architectures. With CMake you specify your target architecture to the toolchain like so:
ANDROID_ABI and ANDROID_NATIVE_API_LEVEL and ANDROID_TOOLCHAIN_NAME are option arguments to get more specific results from the toolchain
my_chosen_abi is where you select your target architecture ... be it armeabi-v7a or x86 or that new armv8x64 or whatever
my_toolchain_name_and_version is where you choose your version of the cross compiler (eg. arm-linux-androideabi-4.8 )
my_api_level of course is the target NDK api version (eg. 10 for some reason targets android-9 ... never looked into why lol)
Sadly, I'm not sure there's a way to build multiple ABIs at once in CMake like there is with ndk-build. You can definitely build them each separately though. A really good question after that is "how do you link all of the different ABI libs you built separately with CMake into your final android project using ndk-build?". I have that question also, I just haven't answered it yet because I'm not quite to the final stage of submission to google play. This link from google looks promising, but I have yet to try that. Maybe you can be my pioneer on that issue
https://software.intel.com/en-us/blogs/ ... -platforms
Code: Select all
cmake -G"my makefile generator" -DCMAKE_TOOLCHAIN_FILE=/my/toolchain/file -DANDROID_ABI=my_chosen_abi -DANDROID_NATIVE_API_LEVEL=my_api_level -DANDROID_TOOLCHAIN_NAME=my_toolchain_name_and_version
my_chosen_abi is where you select your target architecture ... be it armeabi-v7a or x86 or that new armv8x64 or whatever
my_toolchain_name_and_version is where you choose your version of the cross compiler (eg. arm-linux-androideabi-4.8 )
my_api_level of course is the target NDK api version (eg. 10 for some reason targets android-9 ... never looked into why lol)
Sadly, I'm not sure there's a way to build multiple ABIs at once in CMake like there is with ndk-build. You can definitely build them each separately though. A really good question after that is "how do you link all of the different ABI libs you built separately with CMake into your final android project using ndk-build?". I have that question also, I just haven't answered it yet because I'm not quite to the final stage of submission to google play. This link from google looks promising, but I have yet to try that. Maybe you can be my pioneer on that issue
https://software.intel.com/en-us/blogs/ ... -platforms
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 26
Re: Building Ogre dependencies using NDK
Thanks for yet more info. Part of the appeal for me with ndk is a nice clean structure and 2 files that given the build. I also got all platform files in one build. Admittedly I only use Armeabi for testing and am not at the point of working out how to package the different platforms.
Right now my approach is to debug on Armeabi and worry about the packaging later. Like I said I do like the concept of multiple builds for all platforms from ndk when that day arrives.
I'll share when I get there but like many things it is a question of when.
I'd post my application and Android.mk but since I had to cut out tiff I don't know how valuable it would be for people.
Right now my approach is to debug on Armeabi and worry about the packaging later. Like I said I do like the concept of multiple builds for all platforms from ndk when that day arrives.
I'll share when I get there but like many things it is a question of when.
I'd post my application and Android.mk but since I had to cut out tiff I don't know how valuable it would be for people.
-
- Beholder
- Posts: 1512
- Joined: Fri Feb 22, 2013 4:44 am
- Location: Deep behind enemy lines
- x 139
Re: Building Ogre dependencies using NDK
I doubt anyone is using tiff on android platform. Everyone should be using ETC1 (or ETC2 if targeting minimum of gles3 I guess). Or possibly even building out different versions for PowerVR to use PVRTC or whatever. Google Play sorts out which hardware gets which version for you.
The way you build might be helpful for some. Personally I like the CMake route. Partly because it's the devil I know, but also because I use the same build scripts to build out my 12 different dependencies on 6 different platforms (win7 / windows universal / android / linux / OSX / iOS). But I do agree with what you are saying about the convenience of the android project and how it automatically builds out all your ABI targets. That is convenient, to be sure!
The way you build might be helpful for some. Personally I like the CMake route. Partly because it's the devil I know, but also because I use the same build scripts to build out my 12 different dependencies on 6 different platforms (win7 / windows universal / android / linux / OSX / iOS). But I do agree with what you are saying about the convenience of the android project and how it automatically builds out all your ABI targets. That is convenient, to be sure!