It's hard to say where the error comes from without looking carefully at the code in question. Most likely is a case that the package itself is not compatible with the environment within which you are attempting to build the software. With that said, it's possible to track it down, if you are willing to do so. From there, the solution is likely either changing settings at the start of the build process, or modifying the code to correct a mistake.
This problem is tricky to track down since it's a third-party package performing the includes. And, if it's written to build on multiple architectures, it will likely contain a lot of preprocessor directives that make it hard to even know which code is actually being used.
I recommend capturing the command that generates the error (looks like that may be CC libc/inet/if_index.os
although CC of an os file seems odd), then modify the cc
command to capture the preprocessed output.
For example, to get preprocessed output from this:
cc -c prog.c -o prog.o
Use this intead:
cc -E prog.c >prog.i
Then search though prog.i for the line in question. It's tricky to locate specific line numbers, so it's best to search for text - although that can be tricky too since some words will be replaced by the preprocessor. The good news here is that the output will tell you exactly what the compiler is trying to compile - after all includes have been processed and macros applied. Just "pure C" code.
Do this on the version that works and the one that does not, and see where __kernel_long_t
gets pulled into the build on the good one, and then try to find why that's not happening on the failing one.
Note the lines that look like this:
# 443 "/usr/include/stdio.h"
mean "line 443" of "/usr/include/stdio.h" is the next line in the output file.
To see where a definition comes into the sources, search up from the line that contains the definition, probably a typedef as indicated in the question, and search up for the first line above that with a filename - that's the file from which it was obtained. Walk up more to see where that file was pulled in. Note that it won't necessarily be the next file above, so verify against the original sources. Doing this, eventually you'll find the part of the packaged sources that included a file with that definition. Then it should be possible to figure out why either that line isn't used in the other build, or that the same include doesn't lead to the definition of the type.
Note that I'm assuming that the error messages posted mean the problem is the missing definition for __kernel_long_t
. The error could mean something just before the use of that type is a problem.
I hope this helps.