"ndk-which strip" on windows returns empty string

[Mark Simpson]

Hi,

I've run into a problem with ndk. As part of our build process, we have a shell script that calls:

ndk-which strip

... and then uses the return value to strip the binaries we've just built. This works perfectly on os x, but writes to stderr + returns an empty string on windows (or worse, if you have strip in your path elsewhere, ndk-which returns that version instead). Similarly, the items in the ndk-which help spew (gdb, gcc, objdump) cannot be found.

Here's the output on windows 7 (64 bit) with NDK r9d / r10d:

$ ndk-which strip
/c/android-ndk-r9d/ndk-which: line 44: make: command not found <- stderr

Here's the output on OS X Yosemite (10.10.2) with NDK r9d:

$ ndk-which strip
/Users/mark.simpson/Development/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-strip

If I manually find & invoke the version I need (e.g. by changing the build script to have a hard-coded path of C:\android-ndk-r9d\toolchains\arm-linux-androideabi-4.6\prebuilt\windows-x86_64\bin\arm-linux-androideabi-strip.exe) then it functions as expected, the problem is that ndk-which isn't returning the path to the tool.

So my question is basically, how do I get the correct version of strip when using windows?

We generally use NDK r9d with GCC 4.6 for our C++ default build, but also build a C++11 version of our software using GCC 4.8, so I'm reluctant to hard-code paths or hack up our build scripts, as we have several developers and build agents to maintain. 

I noticed that ndk-which is a shell script that actually invokes make (which exists on my mac, but not on my windows machine), so I'm guessing that may be something to do with it? I know the NDK documentation used to talk about installing cygwin/make, but I've not noticed any mention of these in the r10d documents. 

I'd appreciate any suggestions on how to get past this problem, or alternative approaches I should consider.

Thanks,
Mark

[Mark Simpson]

I eventually gave up on doing this properly. My workaround for windows machines: 

• upgrade to r10d (so that GCC 4.8 is used for both C++/C++11 builds, making it possible to know ahead of time which toolchain is active) 
• install the ndk in a consistent location on windows machines 
• for windows builds, rather than querying ndk-which, hard-code the strip path to the 4.8 armeabi version ( android-ndk-r10d\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x86_64/bin/arm-linux-androideabi-strip.exe ) 

Not fantastic, but it gets us over the hump for now. The downside is that this is quite fragile. If we change toolchain, we'll need to update the scripts.