Re: build breaker/Issue 126449/ svx module
On 30 Aug, To: dev@openoffice.apache.org wrote: > On 29 Aug, Don Lewis wrote: >> On 14 Aug, Andrea Pescetti wrote: >>> Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 >>> (where a patch by Ariel is available, but operates at a C++ code level >>> and not at a Makefile level)? >> >> Yes. Early on I saw the LibreOffice folks do something similar, but I >> was not able to get that to work reliably and switched to -O0 >> optmization for a long time. My workaround above is fairly recent. > There are some hooks in the build specific files with optimization > disabled, so adding the above two files to that list is one possible > fix, though I don't know if that hook is present in both parts of the > build framework, but it looks like it is. I attached another patch to https://bz.apache.org/ooo/show_bug.cgi?id=125475 that disables optimization of the troublesome files. In one case the compiler version information is available, so I only disable optimization for gcc 4.9. Optimization of the other file is always disabled when compiling with any version of gcc. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
On 29 Aug, Don Lewis wrote: On 14 Aug, Andrea Pescetti wrote: On 09/08/2015 Don Lewis wrote: Looks like you are compiling with gcc 4.9. I ran into this same problem on FreeBSD and worked around it by changing the -Os optimization flag ... This is a gcc bug, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009 This looks like very valuable information (I never saw this, but I build with gcc 4.8.x most of the times). Could you expand on it a bit? It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc 5 and was not present in 4.8. It is sometimes triggered by inline virtual class methods. I believe it only happens with -Os optimization. The workaround is to either disable optimization by using -O0, or disabling the problematic optimization step by using -fno-devirtualize -fno-devirtualize-speculatively, which I figured out based on comment #2 in the gcc bug report. I didn't attempt to figure out if only one of the flags would be sufficient. Do I understand correctly from the above issue than anybody building OpenOffice (I'm obviously particularly interested in the coming 4.1.2) with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the issue is not fixed yet in 4.9.x) will have to manually edit their makefiles? Yes. If this is true, would you recommend that we either detect it at configuration time, or modify the makefiles, or anything else? It would be nice to detect it at configuration time, but configure doesn't really look at the compiler version. One half of the build framework does decipher the compiler version and that could be leveraged to change the optimization flags for gcc 4.9, but the other half of the build framework does not. Unfortunately there are two instances where this is broken, and the fix needs to be done in both places. I maintain the FreeBSD port and the approach that I took for package building is to detect the use of gcc 4.9 in the port Makefile, and then patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is detected. I didn't need to patch unxfbdx.mk because it uses -O2 optimization on x86_64. Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 (where a patch by Ariel is available, but operates at a C++ code level and not at a Makefile level)? Yes. Early on I saw the LibreOffice folks do something similar, but I was not able to get that to work reliably and switched to -O0 optmization for a long time. My workaround above is fairly recent. As I recall, when I tried something similar to the patch in the bug report, it fixed the problem on x86_64, but not intel. The problem potentially affects two files, fmgridif.cxx and ColumnControl.cxx. The out of the box build on FreeBSD builds one of those with -Os and the other with -O2 on x86_64. Since the gcc bug is only triggered when using -Os, only one of the resulting .o files has the problem, and it is fixed by the patch. On intel, both files are built with -Os, so both .o files have the problem. The patch fixed one of them and the undefined symbols were exported, but they were exported as weak symbols and were not visible outside of the shared library that the .o file was linked into. The .o file that remained broken was linked into another shared library and wasn't able to see the symbols from the fixed .o file. Patching the source to attempt to export these symbols is the wrong thing to do in any case. These are for class methods that are defined in the class declaration, so the expectation is that the compiler will inline them wherever they are used. There are some hooks in the build specific files with optimization disabled, so adding the above two files to that list is one possible fix, though I don't know if that hook is present in both parts of the build framework, but it looks like it is. Another possibility is to globally change -Os to -Os -fno-devirtualize -fno-devirtualize-speculatively when building with gcc. On the solenv/inc side, this would involve patching these files: os2.mk unxfbsdi.mk unxfbsdppc.mk unxlngi.mk unxlngm68k.mk unxlngmips.mk unxlngppc.mk unxlngr.mk unxlngs.mk Since CCUMVER is available, this could be made conditional on the gcc version. On the gbuild/platform side, the files to change are: freebsd.mk linux.mk os2.mk winmingw.mk Since CCNUMBER is not available here, the optmiization change would affect all gcc versions. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
On 14 Aug, Andrea Pescetti wrote: On 09/08/2015 Don Lewis wrote: Looks like you are compiling with gcc 4.9. I ran into this same problem on FreeBSD and worked around it by changing the -Os optimization flag ... This is a gcc bug, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009 This looks like very valuable information (I never saw this, but I build with gcc 4.8.x most of the times). Could you expand on it a bit? It apparently is an optimizer bug in gcc 4.9 that has been fixed in gcc 5 and was not present in 4.8. It is sometimes triggered by inline virtual class methods. I believe it only happens with -Os optimization. The workaround is to either disable optimization by using -O0, or disabling the problematic optimization step by using -fno-devirtualize -fno-devirtualize-speculatively, which I figured out based on comment #2 in the gcc bug report. I didn't attempt to figure out if only one of the flags would be sufficient. Do I understand correctly from the above issue than anybody building OpenOffice (I'm obviously particularly interested in the coming 4.1.2) with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the issue is not fixed yet in 4.9.x) will have to manually edit their makefiles? Yes. If this is true, would you recommend that we either detect it at configuration time, or modify the makefiles, or anything else? It would be nice to detect it at configuration time, but configure doesn't really look at the compiler version. One half of the build framework does decipher the compiler version and that could be leveraged to change the optimization flags for gcc 4.9, but the other half of the build framework does not. Unfortunately there are two instances where this is broken, and the fix needs to be done in both places. I maintain the FreeBSD port and the approach that I took for package building is to detect the use of gcc 4.9 in the port Makefile, and then patch the freebsd.mk and unxfbsdi.mk on the fly when gcc 4.9 is detected. I didn't need to patch unxfbdx.mk because it uses -O2 optimization on x86_64. Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 (where a patch by Ariel is available, but operates at a C++ code level and not at a Makefile level)? Yes. Early on I saw the LibreOffice folks do something similar, but I was not able to get that to work reliably and switched to -O0 optmization for a long time. My workaround above is fairly recent. Sorry for the many questions! At the bare minimum, it would be very helpful if you can update the building guide at https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step with some specific information; I know you build on FreeBSD which is not one of the platforms we provide binaries for, but you can add a whole section about it if you like. If you need a wiki account, just ask here. It would really be nice if this just worked out of the box. For the stuff that uses solenv/inc to build, the compiler version is available in $(CCNUMVER), which can be tested in the target .mk files to adjust the optimization flags. Unfortunately $(CCNUMVER) is not available on the solenv gbuild side. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
On 09/08/2015 Don Lewis wrote: Looks like you are compiling with gcc 4.9. I ran into this same problem on FreeBSD and worked around it by changing the -Os optimization flag ... This is a gcc bug, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009 This looks like very valuable information (I never saw this, but I build with gcc 4.8.x most of the times). Could you expand on it a bit? Do I understand correctly from the above issue than anybody building OpenOffice (I'm obviously particularly interested in the coming 4.1.2) with GCC 4.9.0 to 4.9.3 (and possibly later 4.9.x releases, since the issue is not fixed yet in 4.9.x) will have to manually edit their makefiles? If this is true, would you recommend that we either detect it at configuration time, or modify the makefiles, or anything else? Is this related to https://bz.apache.org/ooo/show_bug.cgi?id=125475 (where a patch by Ariel is available, but operates at a C++ code level and not at a Makefile level)? Sorry for the many questions! At the bare minimum, it would be very helpful if you can update the building guide at https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step with some specific information; I know you build on FreeBSD which is not one of the platforms we provide binaries for, but you can add a whole section about it if you like. If you need a wiki account, just ask here. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
Hi Don, your assumption is correct: gcc (Debian 4.9.2-10) 4.9.2 and the solution did solve this problem. cheers Martin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: build breaker/Issue 126449/ svx module
On 8 Aug, Martin Bakker wrote: Hi There, I'm a developer using AOO in some of my applications. To debug some AOO problems I decided to build AOO with symbols to try and find a solution. I followed the instructions on how to build but got stuck when trying to build the svx module. used svn to get fresh start and tried building without debug, same problem. I opend an Issue on bugzilla but was kindly directed this way. see the issue for a complete log. configure was run like: configure --with-package-format=installed --disable-gnome-vfs trying to build fails with : [ build LNK ] Library/libsvxcore.so /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: In function `FmXGridControl::createPeer(com::sun::star::uno::Referencecom::sun::star::awt::XToolkit const, com::sun::star::uno::Referencecom::sun::star::awt::XWindowPeer const)': fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to WindowListenerMultiplexer::acquire()' /usr/bin/ld: /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: relocation R_X86_64_PC32 against undefined symbol `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when making a shared object; recompile with -fPIC Looks like you are compiling with gcc 4.9. I ran into this same problem on FreeBSD and worked around it by changing the -Os optimization flag in main/solenv/gbuild/platform/freebsd.mk and main/solenv/inc/unxfbsdi.mk to: -Os -fno-devirtualize -fno-devirtualize-speculatively The files controlling this on your platform will be different. This is a gcc bug, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
build breaker/Issue 126449/ svx module
Hi There, I'm a developer using AOO in some of my applications. To debug some AOO problems I decided to build AOO with symbols to try and find a solution. I followed the instructions on how to build but got stuck when trying to build the svx module. used svn to get fresh start and tried building without debug, same problem. I opend an Issue on bugzilla but was kindly directed this way. see the issue for a complete log. configure was run like: configure --with-package-format=installed --disable-gnome-vfs trying to build fails with : [ build LNK ] Library/libsvxcore.so /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: In function `FmXGridControl::createPeer(com::sun::star::uno::Referencecom::sun::star::awt::XToolkit const, com::sun::star::uno::Referencecom::sun::star::awt::XWindowPeer const)': fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to WindowListenerMultiplexer::acquire()' /usr/bin/ld: /home/martin/Downloads/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: relocation R_X86_64_PC32 against undefined symbol `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when making a shared object; recompile with -fPIC Kind Regards, Martin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
