Strange gcc #include behavior when compiling multiple source files at once

Strange gcc #include behavior when compiling multiple source files at once

[Alfred von Campe]

I have a shell script which is run as root (with sudo) that contains the following line
(split here for readability):

    $STTOOLPATH/sh4-linux-gcc -O2 $EXTRA_PREPROCESSOR_DEFINE $RELEASE_DEFINE \
    -I../../../../Components/Messaging -I../AvRouting/AVRD/Main -I../IPC/common_files \
    -I../OSAbstraction -I../IPC/LPMLib -I../../Drivers/LPM -I../../Drivers/AVRDriver \
    -I../../Drivers/Diagnostics -I../../../LPM/share -I../../../LPM/LPMcode \
    -I$KERNELSOURCES/include ../IPC/LPMLib/*.c  ./xxxx_init.c ./init_frame_buffer.c \
    ./init_v4l.c -o $FILESYSTEM_TARGET/sbin/xxxx_init || cleanup 1

Recently, we moved some header files from ../../../LPM/LPMcode to ../../../LPM/share,
both of which are listed with -I in the compile line above.  When the driver tries to
compile the init_frame_buffer.c file, it complains that it cannot find a particular
include file that was moved from LPMcode to share.  Here is the strange part: when
I add -save-temps to the above line, the resulting init_frame_buffer.i file clearly
shows the contents of the missing include file.  If I cut and past the above line in
the script, pre-pend "echo" and remove the trailing "|| cleanup 1" so I can capture
the command line, and then cut & paste that command line into my xterm window, it works
just fine.  If I copy the troublesome include file from share to LPMcode it also works.

I've tried messing with the order of things on the gcc command line to no avail.  How
can I debug this further?  Why is gcc getting confused?  In case it matters, here is
the compiler version, which I am stuck with since it's delivered by our chip vendor:

    sh4-linux-gcc (GCC) 4.2.4 (snapshot) (STMicroelectronics/Linux Base 4.2.4-54)
    Copyright (C) 2007 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And for completeness' sake, here is the actual command line from the echo command
and (truncated) compiler output of the error:

    /opt/STM/STLinux-2.3/devkit/sh4/bin/sh4-linux-gcc -save-temps -O2 \
    -I../../../../Components/Messaging -I../AvRouting/AVRD/Main -I../IPC/common_files \
    -I../OSAbstraction -I../IPC/LPMLib -I../../Drivers/LPM -I../../Drivers/AVRDriver \
    -I../../Drivers/Diagnostics -I../../../LPM/share -I../../../LPM/LPMcode \
    -I/opt/STM/STLinux-2.3/devkit/sources/kernel/havana-linux-sh4/include ../IPC/LPMLib/*.c  \
    ./xxxx_init.c ./init_frame_buffer.c ./init_v4l.c -o /dev/shm/usb_update.10255/filesystem/sbin/xxxx_init

    ./init_frame_buffer.c:27:25: error: ipc_defines.h: No such file or directory
    ./init_frame_buffer.c: In function ‘init_frame_buffer’:

Re: Strange gcc #include behavior when compiling multiple source files at once

[Jonathan Wakely]

On 6 December 2011 14:07, Alfred von Campe wrote:
>
> I've tried messing with the order of things on the gcc command line to no avail.  How
> can I debug this further?

The most basic step would be to add -v to the command line and inspect
the output (it's not clear from your email if you've already done
that.)

That will show you any directories specified with -I which don't
exist, and will show you the include paths being used:
#include "..." search starts here:
#include <...> search starts here:
...

Re: Strange gcc #include behavior when compiling multiple source files at once

[Alfred von Campe]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Dec 6, 2011, at 9:19, Jonathan Wakely wrote:

> The most basic step would be to add -v to the command line and inspect
> the output (it's not clear from your email if you've already done
> that.)

No, I had not.  I just did and can't quite decipher what (if anything) the
output is trying to tell me.  Would you (or someone else on this list) try
to take a stab at it?  I've attached the (slightly redacted) log file.  But
keep in mind that the init_frame_buffer.i file contains the contents of the
ipc_defines.h include file despite the compiler complaining about "No such
file or directory" as I mentioned in my original post.  Creating a symlink
from ../../../LPM/LPMcode/ipc_defines.h to ../../../LPM/share/ipc_defines.h
makes the compiler happy, even though both directories are specified with -I
on the command line.

Alfred


[-- Attachment #2: gcc.log.gz --]
[-- Type: application/x-gzip, Size: 2495 bytes --]

Re: Strange gcc #include behavior when compiling multiple source files at once

[Alfred von Campe]

On Dec 6, 2011, at 9:07, I wrote:

> I have a shell script which is run as root (with sudo) that contains the following line
> (split here for readability):

Sigh, this was not a compiler problem after all, but rather a problem in
the shell script.  There were additional instances of the compile line I had
problems with, and it was one of the other instances that had the problem.
This is a very messy shell script so it was hard to figure out.  I am
starting to re-write portions of it to use make, which will not only speed
it up, but also make it easier to debug.  Sorry for the false alarm...

Alfred