Apache OpenOffice (AOO) Bugzilla – Issue 26518
chart2 and template instantiation depth exceeds maximum of 50
Last modified: 2013-02-24 21:19:54 UTC
Hi, gcc 3.0.4 gives me this message: Making: ../../../unxlngi4.pro/slo/ChartTypeManager.obj /home/oo/BuildDir/ccache /opt/experimental/bin/g++ -fmessage-length=0 -c -I. -I. -I../inc -I../../../source/inc -I../../../inc -I../../../unx/inc -I../../../unxlngi4.pro/inc -I. -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc/stl -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc/external -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solenv/unxlngi4/inc -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solenv/inc -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/res -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc/stl -I/home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solenv/inc/Xp31 -I/usr/lib/java/include -I/usr/lib/java/include/linux -I/usr/lib/java/include/native_threads/include -I/usr/X11R6/include -I. -I../../../res -I. -O1 -pipe -mcpu=pentiumpro -fno-rtti -include preinclude.h -fexceptions -fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC300 -DINTEL -DGXX_INCLUDE_PATH=/opt/experimental/include/g++-v3 -DCVER=C300 -D_USE_NAMESPACE -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRC680 -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../unxlngi4.pro/slo/ChartTypeManager.o /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/chart2/source/model/template/ChartTypeManager.cxx In file included from ../../../source/inc/InlineContainer.hxx:141, ... many same lines deleted... from ../../../source/inc/InlineContainer.hxx:141, from /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc/stl/stl/_map.h:133, from /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/chart2/source/model/template/ChartTypeManager.cxx:352: ../../../source/inc/InlineContainer.hxx:141: template instantiation depth exceeds maximum of 50 (use -ftemplate-depth-NN to increase the maximum) instantiating `comphelper::MakeMap<Key, Value>& comphelper::MakeMap<Key, Value>::operator()(const Key&, const Value&) [with Key = rtl::OUString, Value = <unnamed>::TemplateId]' ../../../source/inc/InlineContainer.hxx:141: instantiated from `comphelper::MakeMap<Key, Value>& comphelper::MakeMap<Key, Value>::operator()(const Key&, const Value&) [with Key = rtl::OUString, Value = <unnamed>::TemplateId]' ... ../../../source/inc/InlineContainer.hxx:141: instantiated from `comphelper::MakeMap<Key, Value>& comphelper::MakeMap<Key, Value>::operator()(const Key&, const Value&) [with Key = rtl::OUString, Value = <unnamed>::TemplateId]' ../../../source/inc/InlineContainer.hxx:141: instantiated from `comphelper::MakeMap<Key, Value>& comphelper::MakeMap<Key, Value>::operator()(const Key&, const Value&) [with Key = rtl::OUString, Value = <unnamed>::TemplateId]' /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/solver/680/unxlngi4.pro/inc/stl/stl/_map.h:133: instantiated from `_STL::map<_Key, _Tp, _Compare, _Alloc>::map(const _STL::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = rtl::OUString, _Tp = <unnamed>::TemplateId, _Compare = _STL::less<rtl::OUString>, _Alloc = _STL::allocator<_STL::pair<const rtl::OUString, <unnamed>::TemplateId> >]' /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/chart2/source/model/template/ChartTypeManager.cxx:352: instantiated from here dmake: Error code 1, while making '../../../unxlngi4.pro/slo/ChartTypeManager.obj' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /home/oo/BuildDir/ooo_cws_src680_ooo20040329_src/chart2/source/model/template dmake: Error code 1, while making 'build_all' ./chart2/source/controller/dialogs/dlg_ChartType.cxx ./chart2/source/model/template/ChartTypeManager.cxx Commenting several lines "helped" (at least to finish the compilation). Attached patch to demonstrate *WRONG* solution.
Created attachment 13827 [details] *Wrong* patch that made it compile to demonstrate problem
for you
please have a look.
.
CC to mh
Note: What is compiled here is not really a nested template. It is a template-object for which the operator() is called in a nested way. gcc 3.2 also compiles with -ftemplate-depth-17, so I assume that the expression is parsed differently in both compilers (and IMO in 3.2 in a more correct way). Should also work with 3.0 when setting -ftemplate-depth-64 (Something bigger than 57).
mh->pavel: what about conditional extend of CFLAGS+=-ftemplate-depth-64 for SHORTSTDCPP3=="3" in the makefile.mk ? better way would be the upgrade of the compiler, if we'll get to many problems like that, we might consider to drop 3.0.x support for 2.0.
mh: this kind of ideas will come to my mind only if I'm going to hear that the code is written in the only correct way :-) I do not know C++ to such extend to judge it myself.
I can not solve this issue. We can abandon gcc 3.0.4 or fix it. I can't do any of those :-)
Created attachment 13893 [details] patch for gcc3.0 (compiler-flags in makefiles)
Hi Pavel, could you please check whether the added patch works with gcc3.0.4. If so, I would suggest to apply the patch in a recent CWS.
I checked this patch and chart2/source/controller/dialogs/makefile.mk needs at least 67 chart2/source/model/template/makefile.mk needs at least 66 Hmm 8) Why different value (it really is different, I double checked)? See ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/build/Patches/OOo_cws_src680_ooo20040329_source-TEMP-chart2.diff I will use this patch for now, but do you plan to add more "entries" there? If yes, I should use higher value here. Hmm, this is really GCC's bug and I think it is not worth the effort to put in cws and we should deprecate 3.0.4. It should have been only for gcc, only for specific version, in two files. Now, but in the future, we will find other issues. And it is not worth the effort. I will continue to use it for 1.1.x but will upgrade to newer version for 2.0. Thanks for your help! Martin, reassigning to you to finally decide.
this seems a compiler issue, even 2.95 is working :). so I will have to announce 3.0.x compiler as deprecated for 2.0 development.
verifying
close issue.