Cross compiling to arm-linux using cygwin

I am trying to cross-compile strace using cygwin to Android emulator. I used this article as my starting point. I installed the cross-compiler following these instructions. Then I prepared the makefile using

./configure -host=arm-linux

Now when I do make I get the following error:

$ make
make  all-recursive
make[1]: Entering directory `/home/bruce/strace-4.6'
Making all in tests
make[2]: Entering directory `/home/bruce/strace-4.6/tests'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/bruce/strace-4.6/tests'
make[2]: Entering directory `/home/bruce/strace-4.6'
arm-linux-gcc -DHAVE_CONFIG_H -I.  -I./linux/arm -I./linux -I./linux  -Wall开发者_JAVA百科 -Wwr
ite-strings -g -O2 -MT block.o -MD -MP -MF .deps/block.Tpo -c -o block.o block.c

block.c: In function `block_ioctl':
block.c:198: error: `u64' undeclared (first use in this function)
block.c:198: error: (Each undeclared identifier is reported only once
block.c:198: error: for each function it appears in.)
block.c:271: error: `BLKTRACESTOP' undeclared (first use in this function)
make[2]: *** [block.o] Error 1
make[2]: Leaving directory `/home/bruce/strace-4.6'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bruce/strace-4.6'
make: *** [all] Error 2

This occurs even if I append -static after CFLAGS variable in Makefile (Why do I need to do this?). Please help.

Here are the lines 198-206:

case BLKGETSIZE64:
        if (exiting(tcp)) {
            uint64_t val;
            if (syserror(tcp) || umove(tcp, arg, &val) < 0)
                tprintf(", %#lx", arg);
            else
                tprintf(", %" PRIu64, val);
        }
        break;

First of all, what's BLKGETSIZE64 #defined as? There might be a "u64" token hiding in the definition.

Is a 64-bit int actually a well defined object as far as arm-linux-gcc is concerned? Just a thought...but it must be, right?

And the -static addition to CFLAGS causes the binary program to be linked statically, as opposed to dynamically. That means that all the code it needs to run will be built into the executable. Ordinarily, it would dynamically link to Shared Object libraries (.so files, DLLs under Windows), but you can't necessarily count on the particular libraries that your program needs being included in an embedded device. Rather than install all the libraries on the handheld, you can (probably) save space by just building the relevant bits into your executable.