GCC strange behaviour with full path include vs search path include

Question

I've encountered GCC include behavior that I'm trying to understand. The example I'm providing is the simplest test code, the actual code (and this behavior) are the result of a tool I'm using to instrument my code. I have to use this tool. I'm just trying to understand the reasons for getting the error. Interestingly enough, g++ works fine. Here's the example:

If I include <sys/types.h> everything compiles just fine, but if I include "/usr/include/sys/types.h" then I get an error.

Here's the error I get running the first gcc command below that includes the full path:

In file included from hello.c:7: /usr/include/sys/types.h:195: error: redefinition of typedef ‘int8_t’ hello.c:5: error: previous declaration of ‘int8_t’ was here

Compiler command, using GCC 4.1.2 (CentOS 5) cause the error:

gcc -g -I. --verbose -c -o hello.o -DLONG_INCLUDE hello.c

or this one that does not cause the error

gcc -g -I. --verbose -c -o hello.o hello.c

Code:

/* hello2.h */ #ifdef _cplusplus extern "C" { #endif int myFunc(int *a); #ifdef _cplusplus } #endif /* hello.c */ #include <stdio.h> #include <string.h> typedef signed char int8_t; #ifdef LONG_INCLUDE #include "/usr/include/sys/types.h" #else #include <sys/types.h> #endif #include "hello.h" int myFunc(int *a) { if (a == NULL) return -1; int b = *a; b += 20; if (b > 80) b = 80; return b; }

Thank you

UPDATE:

After looking at preprocessor output via gcc -E it looks like when specifying the full path, gcc does not treat it as a system include path and that, somehow, is contributing (causing?) the error. Tries to use the -isystem option for /usr/include and /usr/include/sys but to no avail.

Probably unrelated: The macro is named __cplusplus. You are missing an underscore. Also, all this compiles fine on a non-ancient gcc. — pmr
– pmr, Commented Jun 12, 2012 at 18:53
@pmr Thanks, unfortunately, I'm stuck with the version of GCC and the dang tool. At this point, I'm just trying to understand why does GCC treat it as a non-system header. — Misha M
– Misha M, Commented Jun 12, 2012 at 19:02
As you said,isystem seems to be the way to go here. I would wonder why you need to fully qualify the path in the first place. This seems a little... broken. — pmr
– pmr, Commented Jun 12, 2012 at 19:04
the tool is doing all of that and yeah, it's really broken. What's strange is that isystem does not help — Misha M
– Misha M, Commented Jun 12, 2012 at 19:10
I got the same behaviour with gcc-4.5.1 (is that already ancient, @pmr?). Try setting -D__int8_t_defined, that guards the int8_t and friends typedefs in my <sys/types.h>. — Daniel Fischer
– Daniel Fischer, Commented Jun 12, 2012 at 19:24

Daniel Fischer · Accepted Answer · 2012-06-12 21:08:58Z

In Glibc's <sys/types.h>, the typedefs for int8_t etc. are guarded by

#if !__GNUC_PREREQ (2, 7) /* These types are defined by the ISO C99 header <inttypes.h>. */ # ifndef __int8_t_defined # define __int8_t_defined typedef char int8_t; typedef short int int16_t; typedef int int32_t; # if __WORDSIZE == 64 typedef long int int64_t; # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif # endif

so a workaround for the problem would be to define the guarding macro on the command line, passing -D__int8_t_defined in addition to -DLONG_INCLUDE.

Collectives™ on Stack Overflow

GCC strange behaviour with full path include vs search path include

1 Answer 1

Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Related