MantisBT - GCC-XML
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007215GCC-XMLpublic2008-06-19 18:362008-07-03 09:33
ReporterWilliam Klee 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Summary0007215: fails to process most C++ files giving bogus 'template with C linkage' error
DescriptionThis happens on Mac OS X 10.5.3 and I expect you can reproduce it
on any platform with the attached test case.

This bug makes it impossible to build the open source Python Ogre
package on OS X.

The attached test case, test.ppp, was produced by running the gcc preprocessor on
test.cpp. I did this because the .ppp file captures all the C++ file from the
nested system include files.

run the test like so:

  gccxml test.ppp

Output should be:

  In file included from test.cpp:2:
  /usr/include/c++/4.0.0/i686-apple-darwin9/bits/c++locale.h:55: error: template with C linkage
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? ClinkageTest.taz (5,532) 2008-06-19 18:36
https://public.kitware.com/Bug/file/1540/*
Issue History
Date ModifiedUsernameFieldChange
2008-06-19 18:36William KleeNew Issue
2008-06-19 18:36William KleeFile Added: ClinkageTest.taz
2008-06-26 09:44Brad KingNote Added: 0012528
2008-06-30 12:31William KleeNote Added: 0012578
2008-06-30 13:54Brad KingNote Added: 0012579
2008-06-30 15:38Brad KingNote Added: 0012581
2008-06-30 15:42Brad KingNote Added: 0012582
2008-06-30 16:01Brad KingNote Added: 0012583
2008-06-30 16:10Brad KingNote Added: 0012584
2008-07-03 09:33Brad KingStatusnew => closed
2008-07-03 09:33Brad KingResolutionopen => fixed

Notes
(0012528)
Brad King   
2008-06-26 09:44   
I'm not getting the error with gccxml HEAD from CVS on a linux machine. I ran it on the test.ppp file and it does not get any error. What version of gccxml are you using?
(0012578)
William Klee   
2008-06-30 12:31   
by "HEAD" I assume you mean the latest versions of everything in the gccxml CVS
repository. That's what I'm using. The last checkin was class.c on 6/18/08
and my build includes that.

I have a Fedora system and could try my example there but maybe it would be more
productive to compare our configurations somehow? I poked around the
build directory and couldn't find a useful log file. What do you suggest?

BTW, I'm using this version of gcc:
  gcc version 4.0.1 (Apple Inc. build 5484)

And here is the debug output from gccxml

Using "/Users/anyone/development/gccxml-build/bin/gccxml_cc1plus" as GCC-XML executable.
Using the following arguments to GCC-XML executable:
  "-quiet"
  "-fsyntax-only"
  "-w"
  "-o"
  "/dev/null"
  "-nostdinc"
  "-undef"
  "-D__GCCXML__=900"
  "-D__GCCXML_GNUC__=4"
  "-D__GCCXML_GNUC_MINOR__=2"
  "-D__GCCXML_GNUC_PATCHLEVEL__=1"
  "test.ppp"
  "-D__DBL_MIN_EXP__=(-1021)"
  "-D__FLT_MIN__=1.17549435e-38F"
  "-D__CHAR_BIT__=8"
  "-D__WCHAR_MAX__=2147483647"
  "-D__DBL_DENORM_MIN__=4.9406564584124654e-324"
  "-D__FLT_EVAL_METHOD__=0"
  "-D__DBL_MIN_10_EXP__=(-307)"
  "-D__FINITE_MATH_ONLY__=0"
  "-D__SHRT_MAX__=32767"
  "-D__LDBL_MAX__=1.18973149535723176502e+4932L"
  "-D__APPLE_CC__=5484"
  "-D__UINTMAX_TYPE__=long long unsigned int"
  "-D__SCHAR_MAX__=127"
  "-D__USER_LABEL_PREFIX__=_"
  "-D__STDC_HOSTED__=1"
  "-D__DBL_DIG__=15"
  "-D__FLT_EPSILON__=1.19209290e-7F"
  "-D__GXX_WEAK__=1"
  "-D__LDBL_MIN__=3.36210314311209350626e-4932L"
  "-D__strong="
  "-D__APPLE__=1"
  "-D__DECIMAL_DIG__=21"
  "-D__LDBL_HAS_QUIET_NAN__=1"
  "-D__DYNAMIC__=1"
  "-D__GNUC__=4"
  "-D__MMX__=1"
  "-D__DBL_MAX__=1.7976931348623157e+308"
  "-D__DBL_HAS_INFINITY__=1"
  "-DOBJC_NEW_PROPERTIES=1"
  "-D__cplusplus=1"
  "-D__DEPRECATED=1"
  "-D__weak="
  "-D__DBL_MAX_EXP__=1024"
  "-D__SSE2_MATH__=1"
  "-D__GNUG__=4"
  "-D__LONG_LONG_MAX__=9223372036854775807LL"
  "-D__GXX_ABI_VERSION=1002"
  "-D__FLT_MIN_EXP__=(-125)"
  "-D__DBL_MIN__=2.2250738585072014e-308"
  "-D__FLT_MIN_10_EXP__=(-37)"
  "-D__DBL_HAS_QUIET_NAN__=1"
  "-D__REGISTER_PREFIX__="
  "-D__NO_INLINE__=1"
  "-D__i386=1"
  "-D__FLT_MANT_DIG__=24"
  "-D__VERSION__="4.0.1 (Apple Inc. build 5484)""
  "-Di386=1"
  "-D__i386__=1"
  "-D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1053"
  "-D__SIZE_TYPE__=long unsigned int"
  "-D__FLT_RADIX__=2"
  "-D__LDBL_EPSILON__=1.08420217248550443401e-19L"
  "-D__FLT_HAS_QUIET_NAN__=1"
  "-D__FLT_MAX_10_EXP__=38"
  "-D__LONG_MAX__=2147483647L"
  "-D__FLT_HAS_INFINITY__=1"
  "-D__LITTLE_ENDIAN__=1"
  "-D__EXCEPTIONS=1"
  "-D__LDBL_MANT_DIG__=64"
  "-D__CONSTANT_CFSTRINGS__=1"
  "-D__WCHAR_TYPE__=int"
  "-D__FLT_DIG__=6"
  "-D__INT_MAX__=2147483647"
  "-D__FLT_MAX_EXP__=128"
  "-D__DBL_MANT_DIG__=53"
  "-D__WINT_TYPE__=int"
  "-D__SSE__=1"
  "-D__LDBL_MIN_EXP__=(-16381)"
  "-D__MACH__=1"
  "-D__LDBL_MAX_EXP__=16384"
  "-D__LDBL_MAX_10_EXP__=4932"
  "-D__DBL_EPSILON__=2.2204460492503131e-16"
  "-D__GNUC_PATCHLEVEL__=1"
  "-D__LDBL_HAS_INFINITY__=1"
  "-D__INTMAX_MAX__=9223372036854775807LL"
  "-D__FLT_DENORM_MIN__=1.40129846e-45F"
  "-D__PIC__=1"
  "-D__FLT_MAX__=3.40282347e+38F"
  "-D__SSE2__=1"
  "-D__INTMAX_TYPE__=long long int"
  "-D__GNUC_MINOR__=0"
  "-D__DBL_MAX_10_EXP__=308"
  "-D__LDBL_DENORM_MIN__=3.64519953188247460253e-4951L"
  "-D__PTRDIFF_TYPE__=int"
  "-D__LDBL_MIN_10_EXP__=(-4931)"
  "-D__SSE_MATH__=1"
  "-D__LDBL_DIG__=18"
  "-D__GNUC_GNU_INLINE__=1"
  "-D__private_extern__=extern"
  "-iwrapper/Users/anyone/development/gccxml/GCC_XML/Support/GCC/4.0"
  "-I/Users/anyone/development/root/usr/include"
  "-I/usr/include/c++/4.0.0"
  "-I/usr/include/c++/4.0.0/i686-apple-darwin9"
  "-I/usr/include/c++/4.0.0/backward"
  "-I/usr/local/include"
  "-I/usr/lib/gcc/i686-apple-darwin9/4.0.1/include"
  "-I/usr/include"
  "-include"
  "gccxml_builtins.h"
(0012579)
Brad King   
2008-06-30 13:54   
I've reproduced the problem. It happens only on a mac. This code causes the problem:

  # 1 "test.ppp" 1 3 4
  template <class T> struct A {};

Removing the '4' at the end of the first line fixes it. According to a google search, the meanings of the numbers at the end of the line are:

  1 - enter header
  2 - leave header
  3 - system header
  4 - implicit extern "C"

Obviously the '4' is the culprit.

Strangely, running this minimal example on linux still does not cause the problem. I also need to track down why the preprocessor is putting the '4' there in the first place.
(0012581)
Brad King   
2008-06-30 15:38   
The reason this does not show up on linux is that the header

  GCC/gcc/config/linux.h

defines NO_IMPLICIT_EXTERN_C which disables use of option '4'. It seems no one has been running gccxml on platforms that do not define this macro (until now).
(0012582)
Brad King   
2008-06-30 15:42   
The "4" option is being generated by the 'print_line' function in

  GCC/gcc/c-ppoutput.c

with the code

        fputs (" 3 4", print.outf);

One quick-fix is to hack this line to not add the option. I still need to track down why it is choosing this code path in the first place.
(0012583)
Brad King   
2008-06-30 16:01   
Okay, found it. In

  GCC/gcc/c-opts.c

the handling of the "-isystem" option gccxml uses to specify the native compiler's system path calls 'add_path' from the preprocessor library to add the include path. The third argument to this function is a boolean specifying whether the path's source files are C++ aware, and the default is false. This causes the preprocessor to mark all the system headers as having implicit extern "C" specifiers, which of course does not work for templates.
(0012584)
Brad King   
2008-06-30 16:10   
The builtin configuration of the native Mac GCC already specifies the paths as C++-aware. There does not seem to be a way to get this information from it via the command line though.

Instead, we now just assume all paths are C++-aware:

/cvsroot/GCC_XML/gccxml/GCC/gcc/c-opts.c,v <-- c-opts.c
new revision: 1.5; previous revision: 1.4

This will be a problem only on old platforms that do not have C++-aware C headers. However, gccxml would not have been working on these platforms before this change anyway.