Fix some issues for compiling kaldi for Android

[jcsilva]

After running ./configure in src folder, kaldi.mk is created with some problems.

1. The variable ANDROIDINCDIR is defined, but ANDROIDINC is used.
2. It seems that execinfo.h, which is included at base/kaldi-error.cc is not supported.

This commit treats these issues.

P.S. If you want to repeat all the steps for cross-compiling to Android, please follow the instructions published at http://jcsilva.github.io/2017/03/18/compile-kaldi-android/

[danpovey]

@dogancan, does this look OK to you? And do you think there is a way we can optimally make use of, or link to, his documentation?

[dogancan]

I must have messed these up when updating the build scripts. I think it would be more consistent if we were to replace all occurrences of ANDROIDINCDIR in configure with ANDROIDINC, i.e. sed -i 's/ANDROIDINCDIR/ANDROIDINC/g' src/configure. @jcsilva Do you mind making that change and updating the PR?

Regarding the documentation, we have some platform specific notes at the end of the Kaldi README; maybe we can add a line there linking to the blog post?

[jcsilva]

1. Pull request was updated.
2. When it is approved, I'll update the documentation published in the blog post...Currently it's necessary to edit kaldi.mk manually.

[danpovey]

dogan, when you say it's OK and the checks complete I'll merge.

…

On Sun, Mar 19, 2017 at 2:59 PM, Eduardo Silva ***@***.***> wrote: 1. Pull request was updated. 2. When it is approved, I'll update the documentation published in the blog post...Currently it's necessary to edit kaldi.mk manually. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJVu-qjxT0tFAHF_91v8knWmuSuwF0bks5rnXr6gaJpZM4Mhso9> .

[dogancan]

@danpovey Current changes LGTM. Do you also want to add a few lines to Readme as part of this PR or do you want to handle that separately?

…

Sent from my iPhone

On Mar 19, 2017, at 12:01 PM, Daniel Povey ***@***.***> wrote: dogan, when you say it's OK and the checks complete I'll merge. On Sun, Mar 19, 2017 at 2:59 PM, Eduardo Silva ***@***.***> wrote: > > 1. Pull request was updated. > 2. When it is approved, I'll update the documentation published in the > blog post...Currently it's necessary to edit kaldi.mk manually. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#1502 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ADJVu-qjxT0tFAHF_91v8knWmuSuwF0bks5rnXr6gaJpZM4Mhso9> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[danpovey]

we can deal with the README separately-- perhaps you could take care of that in a separate PR?

…

On Sun, Mar 19, 2017 at 3:06 PM, Dogan Can ***@***.***> wrote: @danpovey Current changes LGTM. Do you also want to add a few lines to Readme as part of this PR or do you want to handle that separately? Sent from my iPhone > On Mar 19, 2017, at 12:01 PM, Daniel Povey ***@***.***> wrote: > > dogan, when you say it's OK and the checks complete I'll merge. > > On Sun, Mar 19, 2017 at 2:59 PM, Eduardo Silva ***@***.*** > > wrote: > > > > > 1. Pull request was updated. > > 2. When it is approved, I'll update the documentation published in the > > blog post...Currently it's necessary to edit kaldi.mk manually. > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > <#1502 (comment)>, or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ADJVu-qjxT0tFAHF_ 91v8knWmuSuwF0bks5rnXr6gaJpZM4Mhso9> > > . > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJVu2vXlmWfuBnNSEnNnw_NrQ-xsAXWks5rnXzAgaJpZM4Mhso9> .

[jcsilva]

Blog post was updated.

[dogancan]

@jcsilva Thanks for the blog post and contributing to Kaldi. I'm adding a few lines to Kaldi README regarding Android cross compilation and planning to give a link to your blog post if you don't mind.

From what I understand you need to patch openfst so that you can compile it with arm-linux-androideabi-g++. I'm wondering if that patch is needed also when you compile openfst with clang++ provided by Android NDK. Did you by any chance try that?

One more thing. Do you mind commenting out the line in the blog post where you are checking out a specific version of Kaldi? In general we recommend people to build the latest Kaldi and people following your instructions blindly might end up with an old version.

[jcsilva]

@jcsilva <https://github.com/jcsilva> Thanks for the blog post and contributing to Kaldi. I'm adding a few lines to Kaldi README regarding Android cross compilation and planning to give a link to your blog post if you don't mind. > Hi Dogan.

It's me who have to thank you. I really like Kaldi project and it's impressive results. I use it daily, so it was a pleasure to contribute. Feel free to publish it wherever you want. I also thought that it could be good idea to send a message to your e-mail list. I've already saw some people looking for a way to compile it for Android, and it could help them. From what I understand you need to patch openfst so that you can compile it with arm-linux-androideabi-g++. I'm wondering if that patch is needed also when you compile openfst with clang++ provided by Android NDK. Did you by any chance try that?

>I patched openfst because I had some problems (like this

<http://stackoverflow.com/questions/22774009/android-ndk-stdto-string-support>) when compiling it with g++. But now I tried with clang++ and I didn't have any issue. I just had to install its headers and libraries when installing Android toolchain. It was easy and I've already updated the blog post for using clang++ when compiling openfst. The unique point I didn't like too much is to build openfst manually. This way, if Kaldi updates its openfst version, you must manually change it. I wrote a remark in the post, but I didn't like this solution. I think it would be better if it could be handled another way. What do you think about it? One more thing. Do you mind commenting out the line in the blog post where

you are checking out a specific version of Kaldi? In general we recommend people to build the latest Kaldi and people following your instructions blindly might end up with an old version. > No problem. I just want to make the blog post fully "reproducible". I

wrote a note advertising everybody to use the latest version of Kaldi and if they get some issue, they could checkout to a specific commit. That is already there in the post. Is it ok for you? —

…

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFRWbE_O40ujLlSkwWGA9_onY1Q1f0sbks5rnbAggaJpZM4Mhso9> .

[dogancan]

@jcsilva Thanks for looking into compiling OpenFst with Android clang++ and addressing my other comment regarding the specific git commit checkout in your blog post which by the way is great!

Regarding cross compiling OpenFst, one approach would be to change the Makefile in tools directory so that when HOST variable is defined in the environment, it adds --host=$HOST to the OpenFst configure call. After that change you should be able to cross-compile OpenFst for Android with the following call in the tools directory as long as Android toolchain is in the path.

CXX=clang++ HOST=arm-linux-androideabi make openfst

@danpovey What do you think?

[danpovey]

I would be OK with that if it makes the overall installation process easier.

…

On Mon, Mar 20, 2017 at 12:15 AM, Dogan Can ***@***.***> wrote: @jcsilva <https://github.com/jcsilva> Thanks for looking into compiling OpenFst with Android clang++ and addressing my other comment regarding the specific git commit checkout in your blog post which by the way is great! Regarding cross compiling OpenFst, one approach would be to change the Makefile in tools directory so that when HOST variable is defined in the environment, it adds --host=$HOST to the OpenFst configure call. After that change you should be able to cross-compile OpenFst for Android with the following call in the tools directory as long as Android toolchain is in the path. CXX=clang++ HOST=arm-linux-androideabi make openfst @danpovey <https://github.com/danpovey> What do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1502 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJVu04VfDynt_4Jb7l4dXSD4V9gqXf7ks5rnf1cgaJpZM4Mhso9> .