Apache OpenOffice (AOO) Bugzilla – Issue 13400
Building with gcc-3.3
Last modified: 2004-06-01 10:39:34 UTC
There are needed some patches to build OpenOffice.org-1.0.2 with gcc-3.3. 1. The version 3.3 must be enabled in cppu/inc/uno/lbnames.h 2. The preprocessor does not allow some invalid concatenations longer 3. gcc-3.3 does not allow the broken code in: dbaccess/source/ui/dlg/tablespage.cxx sw/source/core/swg/sw2block.cxx starmath/source/cfgitem.cxx ... All the attached patches are against OOo-1.0.2 but they are usable for OOo-1.0.3 too.
Created attachment 5642 [details] Enables gcc-3.3 in cppu/inc/uno/lbnames.h
Created attachment 5643 [details] Remove some invalid concatenations
Created attachment 5644 [details] Fixes broken code in dbaccess/source/ui/dlg/tablespage.cxx
Created attachment 5645 [details] Fixes broken code in sw/source/core/swg/sw2block.cxx
Created attachment 5646 [details] Fixes broken code in oo_1.0.2_src/starmath/source/cfgitem.cxx
Created attachment 5647 [details] Adds some missing const marks
retarget to 1.0.4, I take care to get it into Beta2 also.
Hi, Just adding myself as CC to this one to keep up on needed changes for PPC Linux. BTW: It would be good to run the cppu test cases to make sure no alignment changes are needed for gcc 3.3 cd cppuhelper rm -rf unxlng*.pro build debug=TRUE deliver -force cd .. cd cppu rm -rf unxlng* build debug=TRUE deliver -force cd tests dmake debug=TRUE cd .. cd unxlng*.pro/bin ./testcppu It would be interesting to see the results of that running under the very latest gcc 3.3 since I believe there were recent gcc 3.3. changes to fix an alignment issue that has existed since gcc 3.0 and which we work around in the cppu code. Kevin
Ok. I will do the tests. I hope that the results will be awailable tomorow.
Created attachment 5654 [details] Ken Foskey, pointed out this missing patch for solenv/inc/tg_compv.mk
Created attachment 5683 [details] The result of ./testcppu, OOo-1.0.2, gcc-3.3 from SuLi 8.2
I have attached the result of ./testcppu. Can I help to fix the problem? Note: It is no problem to do such tests in the future with newer compilers.
Hi, Your log file is fine. Those assertion failures are intentional and they generate exceptions which are used in the tests. So you passed the tests with flying colors. The key is what CVS date did you grab gcc 3.3 from. The fix for the alignment issue you tested was discussed on the gcc3 list just a few weeks ago. So if you have a moment some time soon can you do a cvs update to the very very latest gcc 3.3 from CVS and give it a try (after rebuilding both cppu and cppuhelper with the new compiler) just ot make sure the alignment issue was not changed in gcc3 after your checked out your copy. I will go back through the gcc archives to find the relevant thread that might impact alignment and get back to you with it just in case you know if that patch went in yet or not. Thanks, Kevin
Hi, The change I am worried about is described in this split thread: http://gcc.gnu.org/ml/gcc/2003-03/msg01196.html http://gcc.gnu.org/ml/gcc/2003-03/msg01318.html http://gcc.gnu.org/ml/gcc/2003-03/msg01411.html http://gcc.gnu.org/ml/gcc/2003-03/msg01533.html http://gcc.gnu.org/ml/gcc/2003-03/msg01548.html http://gcc.gnu.org/ml/gcc/2003-03/msg01549.html http://gcc.gnu.org/ml/gcc/2003-03/msg01553.html http://gcc.gnu.org/ml/gcc/2003-03/msg01557.html So the last thing I heard a fix was going to go into 3.3 but I am not sure if that fix did and if so when. That fix should invalidate the need to use a specific macro that was added to change C++ structure alignment (in cppu/inc/cppu/macro.cxx) to work around the issue. So if you know if the fix for this is going into gcc 3.3 and when, it would be a big help since it should impact OOo. (i.e. that define in macro.hxx in cppu/inc/cppu/ should no longer be needed by OOo) Thanks, Kevin
I have tested the today's gcc-3.3 CVS snapshot. (The tag gcc-3_3-branch). It contains the patch which was mentioned in: http://gcc.gnu.org/ml/gcc/2003-03/msg01497.html I have rebuild cppuhelper, cppu and cppu/test again. The result from ./testcppu follow.
Created attachment 5688 [details] The result of ./testcppu, OOo-1.0.2, gcc-3.3-20030415
I have tried to disable the hack from cppu/inc/cppu/macros.hxx and rebuilt cppuhelper, cppu and cppu/test again. The result from ./testcppu follow.
Created attachment 5689 [details] The result of ./testcppu, OOo-1.0.2 without the hack, gcc-3.3-20030415
Hi, Thanks for those results! From the looks of things we still need the hack in place since the version without the hack had some alignment failures that caued assertions right at the end right in the testcode. So we are good to go for gcc 3.3 in cppu in terms of alignment and we still need the hack. I would have guessed that we would no longer have needed the hack but those assertions say otherwise. Thanks for you help and testing. Kevin
This issue blocks the compilation of Beta 2 under Linux with GCC 3.3.
.. and it blocks builds on Debian unstable when using the default g++ (since g{cc,++,...} 3.3 is now default since some days... I just added the patches and started a build. Let's see...
*** Issue 14701 has been marked as a duplicate of this issue. ***
Created attachment 6325 [details] Mostly added const keywords, *for 1.1Beta2*
These patches are now applied, unfortunately the const updates sometimes break the builds for other compilers. What I think we should do is create a header with #ifdef __GNUC__ == 3 and __GNUC_MINOR__ > 1 # define SAL_ISO_CONST const #else # define SAL_ISO_CONST #endif When we work out whether the .net compiler likes these consts or not we can also add a check for (defined(_MSC_VER) && (_MSC_VER > 1300)) If we were to create this header where would it sit, woudl it be in another similar header?
Created attachment 6335 [details] building setup2/util c++ error messages and environment
see attachment i get c++ error building setup2/util sparc64 linux debian/testing gcc-3.3 (RuntimeException): javaloader error - no C++ environment available also attached are the changes i made to external/gcc3 makefile may be related to issue 12892 ??
Created attachment 6336 [details] external/gcc3_specifice/makefile failed to find so.5
(for cws_srx644_ooo11beta2) My .NET build just stopped in starmath\source\register.cxx due to the const issue. So probably same behavior for both compilers. VC6 stopped (up to now) in: starmath\source\register.cxx sc\source\core\tool\compiler.cxx building ...
With the following three patches const_starmath.diff, const_sc.diff and const_sw.diff both, VC6 and .NET, builds completed.
Created attachment 6339 [details] Patch for starmath
Created attachment 6340 [details] Patch for sc
Created attachment 6341 [details] Patch for sw
Does anyone know if the "const"s that were added recently to the cws_srx644_ooo11beta2 tree remove an error for gcc 3.3 or only a warning? If it's only a warning I'd like to apply const_*.diff ASAP to the beta2 tree to get it into a buildable shape for W32 again!!!
Created attachment 6380 [details] Patch for define specific for gcc 3.3, with comment on purpose.
Hi Ken, Before going through all of this. Can anyone say if the gcc 3.3 compiler is even correct in needing these extra "const" pieces? It is hard to believe that no other compiler (Solaris Forte and Windows) needs these and that adding them actually breaks other compilers. Didn't gcc 3.3 ship with the new parser code? Perhaps some of these are just simply gcc 3.3 bugs that we need to be filing with gcc project so that they get fixed for gcc 3.3.1. Can we post to this comment an example of one file that gcc 3.3 needs const for that breaks a differnt compiler? I am sure we can create a standalone example from it to ask with on the gcc mailing list. Thanks, Kevin
Hi Kevin, Ken is to bed know, but I asked him your question a few minutes ago on IRC: <waratah> vq: did you see my comments on 13400, they are real errors but might actually be a compiler bug with gcc :-( But it doesn't matter, even if it's a compiler bug we have to implement a workaround. gcc 3.3 is shipped with too many distributions to just wait for the next update.
Hi Volker, Who else is shipping gcc 3.3 besides Debian unstable? I thought they were the only ones. I mean it was just officially released last week wasn't it? I still would like to see an simple example of where gcc 3.3 needs a const (or needs to remove const) that another compiler barfs on? Could you post one of those for me (the full error message)? I will then take it and make a simple example out of it and go ask on the gcc mailing list to make sure gcc 3.3 is actually doing the right thing. A followup gcc 3.3.1 could then be released sooner rather than later. Kevin
Hi Ken, I think your sal.const.patch is wrong. It should only use this for gcc 3.3 and not gcc 3.1 and later especially if gcc 3.3 is broken in this regard, gcc 3.2.X compiles this nicely without the controversial const issues. +/* This is to work around a gcc 3.3 error that fixing actually breaks other + * compilers. This will create a dummy variable specifically for gcc 3.3 that + * allows it to compile and not break the others. Other compilers may follow + * with this eror later. */ +#ifdef __GNUC__ == 3 and __GNUC_MINOR__ > 1 +# define SAL_ISO_CONST const +#else +# define SAL_ISO_CONST +#endif + Kevin
Kevin, Suse 8.2 ships with GCC 3.3 prerelease, and I'm pretty sure (don't know) that gentoo also already updated to 3.3. > I still would like to see an simple example of where gcc 3.3 needs a > const (or needs to remove const) that another compiler barfs on? > > Could you post one of those for me (the full error message)? See my const_*.diff patches where I had to remove the const to make it compile with VC 6 again. Aktually you're asking the wrong person for a gcc error message, my notebook would need ages to reach the point where the const is/is not needed and I also don't have the build environment ready to build OOo on that machine. And I don't have another one with a gcc 3.3 around. (Well cygwin doesn't count)
Created attachment 6392 [details] Change to use the new incude file version of const to "fix" other compiles
Created attachment 6393 [details] corrections for the const patch to fix cross compile problems.
Created attachment 6394 [details] patch that allows gcc 3.3 to compile and fixes windows.
I honestly have no idea whether these patches are the result of a broken compiler or not. Please feel free to check them out. The changes did compile correctly under gcc 3.2 which was my verification build, so the if statement is correct as far as I know (it is greater than 1 not >= 1 so it is only picking up gcc 3.2. If you have an older version of gcc 3.2 this could be checked.
Build log after backout, only change was compiler 3.2 compiles fine. ccache g++-3.3 -fmessage-length=0 -c -I. -I. -I../inc -I../../../inc -I../../../unx/inc -I../../../unxlngi4.pro/inc -I. -I/data3/office/solver/644/unxlngi4.pro/inc/stl -I/data3/office/solver/644/unxlngi4.pro/inc/external -I/data3/office/solver/644/unxlngi4.pro/inc -I/data3/office/solenv/unxlngi4/inc -I/data3/office/solenv/inc -I/data3/office/res -I/data3/office/solver/644/unxlngi4.pro/inc/stl -I/data3/office/solenv/inc/Xp31 -I/opt/jdk/include -I/opt/jdk/include/linux -I/opt/jdk/include/native_threads/include -I/usr/X11R6/include -I. -I../../../res -I. -O1 -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti -include preinclude.h -fexceptions -fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC300 -DINTEL -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=644 -DBUILD=8600 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRX644 -DNUM_RELSPACE -DVERTICAL_LAYOUT -DACCESSIBLE_LAYOUT -DBIDI -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../unxlngi4.pro/slo/SwXDocumentSettings.o /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx In file included from /data3/office/solver/644/unxlngi4.pro/inc/sal/types.h:65, from /data3/office/solver/644/unxlngi4.pro/inc/osl/endian.h:66, from /data3/office/solver/644/unxlngi4.pro/inc/vos/macros.hxx:68, from /data3/office/solver/644/unxlngi4.pro/inc/vos/object.hxx:70, from /data3/office/solver/644/unxlngi4.pro/inc/vos/mutex.hxx:69, from /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx:64:/data3/office/solver/644/unxlngi4.pro/inc/sal/config.h:170:17: warning: extra tokens at end of #ifdef directive In file included from /data3/office/solver/644/unxlngi4.pro/inc/com/sun/star/frame/XDispatch.hpp:20, from /data3/office/solver/644/unxlngi4.pro/inc/sfx2/sfxbasecontroller.hxx:78, from /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx:67:/data3/office/solver/644/unxlngi4.pro/inc/com/sun/star/uno/Sequence.hxx: In function `const com::sun::star::uno::Type& getCppuType(const com::sun::star::uno::Sequence<E>*)': /data3/office/solver/644/unxlngi4.pro/inc/com/sun/star/uno/Sequence.hxx:230: warning: `com::sun::star::uno::Sequence<E>::ElementType' is implicitly a typename /data3/office/solver/644/unxlngi4.pro/inc/com/sun/star/uno/Sequence.hxx:230: warning: implicit typename is deprecated, please see the documentation for details /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx: In member function `virtual void SwXDocumentSettings::_setSingleValue(const comphelper::PropertyInfo&, const com::sun::star::uno::Any&)': /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx:474: error: could not convert `SwDoc::GetDBData()()' to `SwDBData&' /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx:481: error: could not convert `SwDoc::GetDBData()()' to `SwDBData&' /data3/office/sw/source/ui/uno/SwXDocumentSettings.cxx:488: error: could not convert `SwDoc::GetDBData()()' to `SwDBData&' dmake: Error code 1, while making '../../../unxlngi4.pro/slo/SwXDocumentSettings.obj' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'do_it_exceptions' ---* TG_SLO.MK *---
First, I still think sal.const.patch should look like this: +#if __GNUC__ == 3 && __GNUC_MINOR__ > 1 Only syntax, not commenting on gcc 3.2 should trigger or not and despite that this "fix" might be the wrong way. And, second to show you what breaks with vc6 with the const set, this is the errorlog for such a case: ------------------------------ Making: ../../../wntmsci9.pro/slo/rangenam.obj guw.pl /cygdrive/c/PROGRA~1/MSVS6/VC98/bin/cl.exe -Zm200 -c -nologo -Gs -Gy -I. -I/w1/cws_srx644_ooo11beta2cyg/solver/645/wntmsci9.pro/inc/offuh -I../inc -I../../../inc -I../../../WIN/inc -I../../../wntmsci9.pro/inc -I. -I/w1/cws_srx644_ooo11beta2cyg/solver/645/wntmsci9.pro/inc/stl -I/w1/cws_srx644_ooo11beta2cyg/solver/645/wntmsci9.pro/inc/external -I/w1/cws_srx644_ooo11beta2cyg/solver/645/wntmsci9.pro/inc -I/w1/cws_srx644_ooo11beta2cyg/solenv/wntmsci9/inc -I/w1/cws_srx644_ooo11beta2cyg/solenv/inc -I/w1/cws_srx644_ooo11beta2cyg/res -I/w1/cws_srx644_ooo11beta2cyg/solver/645/wntmsci9.pro/inc/stl -I/cygdrive/c/jdk1.3.1_02/include/win32 -I/cygdrive/c/jdk1.3.1_02/include -I'/cygdrive/c/psdk02_2003/include' -I/cygdrive/c/PROGRA~1/MSVS6/VC98/include -I. -I../../../res -I. -Zi -Fd../../../wntmsci9.pro/misc\_ooo_st_tool.PDB -Ob1 -Ox -Gd -DWNT -DWNT -DNT351 -DMSC -DMI200 -DINTEL -D_USE_NAMESPACE -D_X86_=1 -DFULL_DESK -DSTLPORT_VERSION=400 -DWINVER=0x400 -D_WIN32_IE=0x400 -D_MT -DCPPU_ENV=msci -DSUPD=645 -DBUILD=8616 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_OFF -DCUI -DSOLAR_JAVA -DSRX645 -DSHAREDLIB -D_DLL_ -DWIN32 -D_MT -D_DLL -DWIN32 -D_MT -D_DLL -DMULTITHREAD -W3 -Fo../../../wntmsci9.pro/slo/rangenam.obj /w1/cws_srx644_ooo11beta2cyg/sc/source/core/tool/rangenam.cxx guw.pl /cygdrive/c/PROGRA~1/MSVS6/VC98/bin/cl.exe @/tmp/mk610cb698.37 Command: /cygdrive/c/PROGRA~1/MSVS6/VC98/bin/cl.exe rangenam.cxx e:\w1\cws_srx644_ooo11beta2cyg\sc\source\core\tool\rangenam.cxx(396) : error C2662: 'Ref' : cannot convert 'this' pointer from 'const class SingleDoubleRefModifier' to 'class SingleDoubleRefModifier &' Conversion loses qualifiers e:\w1\cws_srx644_ooo11beta2cyg\sc\source\core\tool\rangenam.cxx(426) : error C2662: 'Ref' : cannot convert 'this' pointer from 'const class SingleDoubleRefModifier' to 'class SingleDoubleRefModifier &' Conversion loses qualifiers dmake: Error code 2, while making '../../../wntmsci9.pro/slo/rangenam.obj' echo: No match. ERROR: Error 65280 occurred while making /w1/cws_srx644_ooo11beta2cyg/sc/source/core/tool dmake: Error code 1, while making 'build_all' echo: No match.
I have no objection to changing option line to: #ifdef __GNUC__ == 3 and __GNUC_MINOR__ > 2 To match commenting. Can you validate that the patches that I have resupplied work as advertised for Windows. We also need a verification build on gcc 3.0 which exhibits some of these errors as well. These changes with the "special" define may be gcc 3.3 errors, perhaps an upstream bug report is required.
I applied Ken's patches for starmath, sc and sw and used: -- diff -u -r1.18 config.h --- sal/inc/sal/config.h 28 Apr 2003 17:12:43 -0000 1.18 +++ sal/inc/sal/config.h 25 May 2003 10:16:04 -0000 @@ -163,6 +163,16 @@ #define sun sun #endif +/* This is to work around a gcc 3.3 error that fixing actually breaks other + * compilers. This will create a dummy variable specifically for gcc 3.3 that + * allows it to compile and not break the others. Other compilers may follow + * with this eror later. */ +#if __GNUC__ == 3 && __GNUC_MINOR__ > 1 +# define SAL_ISO_CONST const +#else +# define SAL_ISO_CONST +#endif + #endif /*_SAL_CONFIG_H_ */ -- for sal. And starmath, sc and sw build with W32-tcsh / MSVC 6 without problems. Volker
Hi, Based on Matthias's recommendation, I think we should split up gcc-3.3-fixes-for-1.1beta2.patch into pieces (by project or module) and create new P1 issues asking each module owner to evaluate the marked lines as a potential return by value assigned to reference mismatch error. We can simply hand edit the patch to split it up and remove the additional const lines and simply use it to highlight the line for the module owner that gcc 3.3 complained about asking them to check for the mismatch and if so fix it. Is that a plan everyone can agree on? In the emantime, Ken adds his const fixes just to people can continue to build with gcc 3.3. Please let me know if you think that is a good plan of action and I will take a shot at splitting up the patch into pieces. Thanks, Kevin
Sounds fine to me, +1 Volker
I forgot one comment: > In the emantime, Ken adds his const fixes just to people can continue > to build with gcc 3.3. The status at the moment is that gcc 3.3 *is* working, the patches are in, but VC 6 and .NET are failing to build the tree now. With the newest generation of "fixes" also my windows compilers will work again.
Hi, Okay, I have now filed most of the issues to make sure returns by value are not assigned to refernces. These issues are: eventattacher 14860 i18npool 14861 vcl 14862 xmloff 14863 starmath 14864 sw 14865 sc 14866 sch 14867 svx 14869 I am adding them to the list of issues 13400 depends on. I did not feel comfortable making them P1 issues so they are left as P3 issues. If Sander or Martin or Matthias wants to up them to P1, that would be fine with me! Hope this helps, Kevin
Interim patches applied.
<Broken Record> From the GCC "The C preprocessor" manual: Ifdef The simplest sort of conditional is #ifdef MACRO controlled text #endif /* MACRO */ This block is called a conditional group. controlled text will be included in the output of the preprocessor if and only if MACRO is defined. We say that the conditional succeeds if MACRO is defined, fails if it is not. So using #ifdef in: #ifdef __GNUC__ == 3 and __GNUC_MINOR__ > 2 is propably at least undefined. Also "and" is undefined, the expression has to be C Syntax, so use && instead. </Broken Record>
I commited a patch to correct the 'broken record' case
umm... so where are we with this issue? Is it fixed? Not quite fixed? Needs to be reworked? Somewhere inbetween ?
Status is waiting for "Correct" patch for 14864. The kludge I applied still stands in one directory and should be implemented correctly and the kludge removed (from all memory).
I'm starting compile of 11rc with OS X's gcc 3.3. What branch have all these fixes gone into?
The hack in the sal header file must be removed for V2. Grabbing issue for that. MACOSX GCC 3.3 patches are on issue 16413
Mac OS X gcc 3.3 and other patches against ooo11rc3 live in Issue 17274. Dan
gcc 3.3.1 must be current to today. The prerelease version have a problem compiling OpenOffice.org. gcc 3.2.3 has some problem where it gives an internal error if you compile with -g1 (small debugging package). so for gcc 3.2 use either -g or nothing.
Update: all Mac OS X 1.1 + gcc 3.3 issues to date have been dealt with and committed or invalidated.
RC3 will build with gcc 3.3.1. Closing issue. Note early releases of gcc 3.3.1 must be updated to the final release version.
verified. Integrated to head.
closing.
I see this have target OOo 2.0 and fixed. Sorry, is the OOo 1.1.X series really not needed this ? Thanks
Hi Utomo, it was fixed for 1.1.x a loong time ago. See waratah's comment about RC3. Debian builds with g{cc,++} 3.3 since months... Regards, René
Thanks Rene, Sorry I did not look at it.