Opened 14 years ago

Closed 13 years ago

#24541 closed defect (invalid)

gcc43 failed to compile because of typedef conflict

Reported by: rwilsont1@… Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version: 1.8.2
Keywords: Cc:
Port: gcc43

Description

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

Change History (8)

comment:1 Changed 14 years ago by mf2k (Frank Schima)

Keywords: gcc43 removed
Owner: changed from macports-tickets@… to mww@…
Port: gcc43 added

comment:2 Changed 14 years ago by mf2k (Frank Schima)

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

comment:3 in reply to:  2 Changed 14 years ago by 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)

comment:4 Changed 14 years ago by 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.

comment:5 Changed 14 years ago by donnie.smith@…

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

comment:6 in reply to:  4 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Same issue as #28325.

comment:8 Changed 13 years ago by jmroot (Joshua Root)

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.