gcc43 failed to compile because of typedef conflict

[rwilsont1@…]

As a result of trying to install py26-scipy @0.7.1 I need gcc43. The compilation was failing because of a conflict between the type of pointer_t in /usr/include/mach/vm_types.h and that in the module.c file. I introduced the following change in module.c and the compilation proceeded, but it is hard to be sure that it will work correctly. In the end scipy.test() had 4 errors.:

#define P_UNKNOWN 0
#define P_OTHER 1
#define P_NAMESPACE 2
#define P_COMPONENT 3
#define P_SYMBOL 4
#if 0
typedef enum
{
 P_UNKNOWN = 0, P_OTHER, P_NAMESPACE, P_COMPONENT, P_SYMBOL
}
pointer_t;
#endif

The relevant part of the report from using -d is:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc43/work/build/./prev-gcc/xgcc
-B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc43/work/build/./prev-gcc/
-B/opt/local/x86_64-apple-darwin10/bin/ -c   -g -O2 -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings    -DHAVE_CONFIG_H -I. -Ifortran
-I../../gcc-4.3.4/gcc -I../../gcc-4.3.4/gcc/fortran
-I../../gcc-4.3.4/gcc/../include
-I../../gcc-4.3.4/gcc/../libcpp/include -I/opt/local/include
-I/opt/local/include -I../../gcc-4.3.4/gcc/../libdecnumber
-I../../gcc-4.3.4/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.3.4/gcc/fortran/module.c -o fortran/module.o
../../gcc-4.3.4/gcc/fortran/module.c:102: error: conflicting types for 'pointer_
t'
/usr/include/mach/vm_types.h:40: error: previous declaration of 'pointer_t' was
here
make[3]: *** [fortran/module.o] Error 1

[mf2k (Frank Schima)]

What version of Mac OS X are you using? What architecture? What version of Xcode?

[rwilsont1@…]

Replying to macsforever2000@…:

What version of Mac OS X are you using? What architecture? What version of Xcode?

I am running OS X 10.6.3. I had that in the orginal, but after a mail mixup seem to have ommited it. I still can't get email accepted.

Developer Information:

  Version:    3.2 (10M2020)
  Location:    /Developer
  Applications:
  Xcode:    3.2.1 (1613)
  Interface Builder:    3.2.1 (740)
  Instruments:    2.0.1 (1096)
  Dashcode:    3.0 (328)
  SDKs:
  Mac OS X:
  10.5:    (9J61)
  10.6:    (10A432)

[donnie.smith@…]

I ran into this error as well. In my case, it was caused by a symlink from /usr/include/malloc.h to /usr/include/malloc/malloc.h that I had created to satiate an unrelated program. The existence of this header was recognized by gcc's configure script, which caused it to be included by system.h. Unfortunately, malloc/malloc.h includes other type headers that eventually pull in mach/vm_types.h which contains a pointer_t type that conflicts with an unrelated type in module.c.

In short, the fix (for me, at least) was to get rid of the /usr/include/malloc.h I had added.

[donnie.smith@…]

FYI, I'm running OS X 10.6.3 as well.

[ksnelgrove@…]

Replying to donnie.smith@…:

I ran into this error as well. In my case, it was caused by a symlink from /usr/include/malloc.h to /usr/include/malloc/malloc.h that I had created to satiate an unrelated program. The existence of this header was recognized by gcc's configure script, which caused it to be included by system.h. Unfortunately, malloc/malloc.h includes other type headers that eventually pull in mach/vm_types.h which contains a pointer_t type that conflicts with an unrelated type in module.c.

In short, the fix (for me, at least) was to get rid of the /usr/include/malloc.h I had added.

Thanks, this fixed my problem as well. I had linked to /usr/include/malloc/malloc.h from /usr/include/malloc.h for an unrelated problem and had not switched it back. Thanks for posting this! I'm running OS X 10.6.4 & Xcode 3.2.4. This does not occur in 10.5.8 and the build proceeds.

[ryandesign (Ryan Carsten Schmidt)]

Same issue as #28325.

[jmroot (Joshua Root)]

So basically, don't modify /usr/include. Anything that's including malloc.h should be switched to use stdlib.h instead.