1

I'm compiling an mixed C/C++ program using STL with CodeComposerStudio. I have many compiler remarks and link errors

compiler remarks

!defined(__MINGW32__)

!defined(__MINGW32__) "C:/CCStudio_v3.3/C2000_v5.2.5/include/yvals.h",
 line 470: remark #195-D: zero
           used for undefined preprocessing identifier    #if
 199901L <= __STDC_VERSION__
                   ^ "C:/CCStudio_v3.3/C2000_v5.2.5/include/exception", line 181: remark #195-D: 
           zero used for undefined preprocessing identifier    #if
 __GNUC__ < 3 && !defined(__APPLE__) && !defined(__MINGW32__)!defined(__MINGW32__)

link errors
UPDATED : Fixed by updating rts2800_ml.lib to latest version (same as compiler).

error: unresolved symbols remain  undefined                          
 ---------
 std::_Raise_handler                
 std::_Throw(const std::exception &)
 std::_String_base::_Xlen() const   
 std::_String_base::_Xran() const   

 error: unresolved symbols remainerror: unresolved symbols remain

Question
Why ??? It seems i'm missing an include or a bunch of defines down there.

Config
CodeComposerStudio V3.3
DSP TMS320C2812
C2000 v5.2.5

TridenT
  • 4,879
  • 1
  • 32
  • 56
  • If found the answer about **linker errors**. The file `rts2800_ml.lib` linked with the project was an old version. By updating to the latest, no more link error. I now only have the ~120 remarks. – TridenT May 29 '11 at 06:02
  • If the library was out of date, are teh headers also perhaps out of date? Libraries and headers normally go hand-in-hand. – Clifford May 29 '11 at 08:55
  • @Clifford: Headers are ok, the library was extracted from the compiler folder and included in the project folder. Historical reasons ;) – TridenT Jun 04 '11 at 06:18
  • Historical reasons aside, there are plenty of good reasons to do that. The paths in the error message however suggest that not all the headers are *project local*. Is it possible that you are using nested headers from a library/compiler version incompatible with your project copies? – Clifford Jun 05 '11 at 09:56
  • I've searched inside all project includes, nowhere these things are defined. – TridenT Jun 07 '11 at 11:17
  • So maybe I need to define few of them to get ride on remarks. I've read interesting things here : http://processors.wiki.ti.com/index.php/TI_Compilers_and_Industry_Standards#C_standard_variants – TridenT Jun 07 '11 at 11:30
  • And TI support is not able to help ... well, I've exchanged 3 emails with them, and they do not know the problem ... – TridenT Jun 07 '11 at 11:31
  • You might do well to specify the -nostdlib or -nodefaultlibs option to prevent the compiler/linker making assumptions of locations of headers and libraries. You will then need to specify them explicitly. – Clifford Jun 07 '11 at 15:20

1 Answers1

4

The remarks for #if 199901L <= STDC_VERSION and #if GNUC < 3 are with respect to the fact that in a test for the value of an undefined macro, the macro is substituted with zero. So in this case GNUC < 3 will be true even when the compiler is not GNUC. It should be qualified with #if defined GNUC && GNUC < 3 or enclosed in an earlier test for defined GNUC or other GNUC specific macro.

If STDC_VERSION is assumed to be zero, then the test #if 199901L <= STDC_VERSION will always be false. The standard macro for this test is in fact STDC_VERSION. However the C standard applied is irrelevant if C++ compilation is used, so a prior test for defined __cplusplus may be appropriate.

These macros are normally predefined by the pre-processor and require no header. For details of predefined macros defining standards, compilers, architectures and OS, see http://predef.sourceforge.net/prestd.html

The linker errors are a different issue and cannot be resolved by #including further files. If you were missing a header, the compilation would fail. Unresolved linker symbols invariably due to missing code. You may not have linked a necessary library or object file, or the code may have been omitted through earlier conditional compilation (code within a false #if...#endif block).

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • ok, I understand the meaning of the define test remarks, but I don't know why these macros are not defined by the compiler. – TridenT May 29 '11 at 06:08
  • They are not defined for compilers that are neither GCC nor MinGW. Specifying that you are using CCS says nothing about what compiler is being used. That may depend on what TI device you are using, and if it is an OMAP device whether the code is for the ARM or the DSP core. The paths suggest that you are using a C20xx device; is that correct? – Clifford May 29 '11 at 08:43
  • In GCC the options -E -Wp,-dM will cause output of defined macros. If you do this on a dummy empty source file, you will get all the predefined macros. Remember to include all other compiler options you are using since this may affect the macros defined. Also make sure that the dummy file is .cpp to get those relevant to C++ compilation. – Clifford May 29 '11 at 08:54