Possible bug in ccfe when using Apache STL

Question

Environment details:
Solaris 10 @ patch version 148888-03
Sun Studio 12.3 (5.12, 2011/11/16)
  I'm attempting to get boost 1.54 to build with this version of Sun Studio.  I ran into a number of issues when trying to get it to build with stlport4 (let alone the default STL implementation) and decided to try the apache STL.
  At one point when trying to build boost I ran into an error and as I delved into the problem I've discovered something extremely weird.  I've been unable to reduce this to a simplified example, so I'll apologize ahead of time when I say you'll need to get the boost source code to see this happen.  Here's the steps:
~  cd /tmp
~  gtar xf ~/Downloads/boost_1_54_0.tar.gz
~  cd boost_1_54_0/
~ BUILD_COMMAND=CC -library=stdcxx4 -I. libs/log/src/process_id.cpp
  ~ ${BUILD_COMMAND} -c
"/usr/include/stdcxx4/loc/_num_put.cc", line 67: Error: The prior declaration for std::num_put<std::_CharT, std::_Iter>::~num_put() has no exception specification.
1 Error(s) detected.
That build command is clearly simplified from what it would've been during a normal boost build, but since it reliably reproduces the error I've omitted the rest of the flags.
My environment is pretty clean; I'll quote variables that could be considered relevant:
~ env | ggrep -P 'PATH|SHELL|LANG|HOSTTYPE|OSTYPE|VENDOR|MACHTYPE|LC_TIME|LC_CTYPE
PATH=/opt/csw/bin:.:/usr/bin:/bin:/usr/local/bin:/bin:/sbin:/opt/sfw/bin
LANG=C
OSTYPE=solaris
VENDOR=sun
MACHTYPE=sparc
LC_CTYPE=C
LC_TIME=C
I'll demonstrate what I consider odd below; it'll probably be more clear through shell examples than from me describing it.  Wherever you see ${BUILD_COMMAND}, it's the same as above:
~ ggrep -lRIP '_num_put.cc' /usr/include $(gfind ${SUNPRO_INSTALL_PATH}/ -type d -name include)
/usr/include/stdcxx4/loc/_num_put.c
/usr/include/stdcxx4/loc/_num_put.cc
/usr/include/stdcxx4/loc/_num_put.h
${SUNPRO_INSTALL_PATH}/prod/include/CC/stlport4/stl/_num_put.h
~ truss -eaf ${BUILD_COMMAND} -c 2>&1 | ggrep -P 'open.*_num_put\.c'
1729: open("/usr/include/stdcxx4/loc/_num_put.cc", O_RDONLY) = 8
... so clearly it's not going through _num_put.c, so it can't be going through the stlport4 header to do it; that means it must be going through _num_put.h (none of the boost headers or code files use this _num_put thing directly)
~ ${BUILD_COMMAND} -c -H 2>&1 | ggrep -P '^\s.*_num_put\.c'
The fact this last one didn't print anything seemed really odd.  This next one is the weirdest though:
~ ${BUILD_COMMAND} -P
~ gsed -e '/^#/d' libs/log/src/process_id.i
~ CC -library=stdcxx4 libs/log/src/process_id.i -c
... produces no errors.  It builds just fine.  Furthermore, if you look at the output in the .i file (or if you use -E instead of -P) you won't see any of the code from _num_put.cc because the pre-processor doesn't spit it out.
Another way to see that:
~ ${BUILD_COMMAND} -c -Qoption ccfe ++boolflag:prepoutstd=true 2>&1 | ggrep -P '~\s*_num_put'
You won't see the destructor it's complaining about from the above.  However, as I demonstrated above (and as the error message clearly demonstrates), it is in fact using the contents of _num_put.cc.
To put the final nail in the coffin, I looked at the output of using -xdumpmacros=%all (after examining how _num_put.h works) and this big of code sort of seals it for me:
~ ${BUILD_COMMAND} -c -xdumpmacros=%all 2>71 | ggrep -P '#define _RWSTD_DEFINE_TEMPLATE_(FIRST|LAST)'
/usr/include/stdcxx4/rw/_defs.h, line 1498: #define _RWSTD_DEFINE_TEMPLATE_FIRST(ignore) 0
/usr/include/stdcxx4/rw/_defs.h, line 1499: #define _RWSTD_DEFINE_TEMPLATE_LAST(ignore) 0
~ gtail -n 28 /usr/include/stdcxx4/loc/_num_put.h
#if _RWSTD_DEFINE_TEMPLATE_FIRST (_NUM_PUT)
# include <loc/_num_put.cc>
#endif /* ... more stuff ... */
There's another #if for _TEMPLATE_LAST later on with another #include line for _num_put.cc, but as demonstrated from the -xdumpmacros thing, both #if lines should not allow it to include _num_put.cc
I believe this is a bug in ccfe.  If there's a straightforward way to force the compiler driver to do the preprocessing and compiling in two steps I believe I could work around this issue, but I don't see a way to do that.
As an aside, could someone point out a way to get some information on undocumented commands and flags?  I found a way to get a listing, but figuring out what they actually do and when they're valid to use is another matter:
~ ${SUNPRO_INSTALL_PATH}/prod/bin/ccfe ++dumpswitches
  ~ ${SUNPRO_INSTALL_PATH}/prod/bin/ccfe ++dumpflags
-Brian

Answer 1

Based on your response to my question about forcing the use of a 3rd party pre-processor, I found I can make this build error go away with the -template=no%extdef option.  I was under the assumption that the compiler wouldn't take it upon itself to automatically 'discover' the .cc file and attempt to use it; I assumed once the pre-processing stage was complete it would only attempt to compile the output from the pre-processor stage.  Clearly that assumption was faulty.
Thank you for the response Steve.  I've put in for the IT team to get/install the updates for us.
-Brian