I had been struggling the whole week with a phenomena I could not nail down. I had an include file that was included as per preprocessor output. However not any effect from the included file could be seen, not even an #error in the first line. No missing file would be reported by the compiler. When I changed #include "file.h" to #include <file.h> it would work.
It turns out the file system locations for system header files and user header files I had configured overlapped. In Apple's GCC these can be separately specified. Apparently the cpp detected the presence of the file and didn't complain about it being missing, but when it was to put the contents of the file into the namespace it would simply not read it, if included the wrong way.
You can detect that this is happening, by looking at the preprocessor output: dig out the line which tells you how the compiler get's called. If it's a pure compilation stage, it will contain somewhere the option '-c' for compiling only. Replace it with '-E' to only do preprocessing instead and have the output written not in a '.o' file, but in a '.i' file instead. If you look into this file, you'll see all include files are now part of the file fed to the C compiler and no '#define' exist any more. However, the preprocessor still inserts comments where it got the definitions from. If you see lines like:
# 74 "/home/user/src/project/src/file1.c" 2
# 1 "/home/user/src/project/include/include1.h" 1
# 75 "/home/user/src/project/src/file1.c" 2
It means that the file include1.h was indeed included from file1.c, but didn't contain anything useful to the compiler. It just noticed line one and then skipped onto the line after the #include directive.
| < Prev | Avanti > |
|---|
