On 6 Sep, Marcus wrote: > Am 09/05/2016 11:00 PM, schrieb Don Lewis: >> On 5 Sep, Marcus wrote: >>> Am 09/05/2016 10:39 PM, schrieb Don Lewis: >>>> On 5 Sep, Marcus wrote: >>>>> Am 09/05/2016 09:33 PM, schrieb Don Lewis: >>>>>> On 5 Sep, Marcus wrote: >>>>>>> Am 09/05/2016 05:39 AM, schrieb Don Lewis: >>>>>>>> On 4 Sep, Don Lewis wrote: >>>>>>>>> On 4 Sep, Marcus wrote: >>>>>>>>>> Thanks a lot. "libXt-devel" was indeed not installed. >>>>>>>>>> >>>>>>>>>> But now it's breaking in svx: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> ============= >>>>>>>>>> Building module svx >>>>>>>>>> ============= >>>>>>>>>> >>>>>>>>>> Entering /share/linux2/aoo/trunk/main/svx/prj >>>>>>>>>> >>>>>>>>>> cd ..&& make -s -r -j1&& make -s -r deliverlog >>>>>>>>>> [ build LNK ] Library/libsvxcore.so >>>>>>>>>> /share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: >>>>>>>>>> In function >>>>>>>>>> `FmXGridControl::createPeer(com::sun::star::uno::Reference<com::sun::star::awt::XToolkit> >>>>>>>>>> const&, >>>>>>>>>> com::sun::star::uno::Reference<com::sun::star::awt::XWindowPeer> >>>>>>>>>> const&)': >>>>>>>>>> fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual >>>>>>>>>> thunk to >>>>>>>>>> WindowListenerMultiplexer::acquire()' >>>>>>>>>> /usr/bin/ld: >>>>>>>>>> /share/linux2/aoo/trunk/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 >>>>>>>>>> /usr/bin/ld: final link failed: Bad value >>>>>>>>>> collect2: error: ld returned 1 exit status >>>>>>>>>> /share/linux2/aoo/trunk/main/solenv/gbuild/LinkTarget.mk:248: recipe >>>>>>>>>> for >>>>>>>>>> target >>>>>>>>>> '/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so' >>>>>>>>>> failed >>>>>>>>>> make: *** >>>>>>>>>> [/share/linux2/aoo/trunk/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so] >>>>>>>>>> Error 1 >>>>>>>>>> dmake: Error code 2, while making 'all' >>>>>>>>>> >>>>>>>>>> 1 module(s): >>>>>>>>>> svx >>>>>>>>>> need(s) to be rebuilt >>>>>>>>> >>>>>>>>> That looks very familiar. What compiler version are you using? >>>>>>> >>>>>>> gcc 4.9.2 >>>>>>> >>>>>>>> Yup, it's gcc 4.9 bug. This is what I did for the FreeBSD port to work >>>>>>>> around this problem: >>>>>>>> <https://bz.apache.org/ooo/show_bug.cgi?id=125475#c8> >>>>>>>> >>>>>>>> Unfortunately $(CCNUMVER) isn't available to gbuild so we can't disable >>>>>>>> optimization of the affected file only for gcc 4.9. >>>>>>> >>>>>>> I'm sorry but the error has not changed. I've compared the patched >>>>>>> "Library_svxcore.mk" file with the original one and only these changes >>>>>>> were made. >>>>>>> >>>>>>> In your patch a "dbaccess/source/ui/uno/makefile.mk" file is mentioned >>>>>>> which I don't have. Is this related to the "--disable-odk" configure >>>>>>> flag I've used and therefore is OK? >>>>>> >>>>>> Hmn, that's strange. That makefile is still present in recent trunk. >>>>>> It' doesn't have any relationship to --disable-odk. >>>>> >>>>> Yesterday I've done my very first checkout and a "svn update" a second >>>>> ago in the directory doesn't got anything new. SWo, it's indeed strange. >>>>> >>>>>>> Is there any other way than to downgrade gcc? >>>>>> >>>>>> For the FreeBSD port, I'm not using that patch due to the lack of >>>>>> $(CCNUMVER) on the gbuild side of thigs. If we had that, then I would >>>>>> have upstreamed the patch. Instead, I'm still using the workaround in >>>>>> the third to last paragraph. The Makefile for the FreeBSD port does >>>>>> this on-the-fly patch: >>>>>> >>>>>> .if ${COMPILER_TYPE} == gcc >>>>>> # g++49 -Os sometimes leaves inline class methods undefined, >>>>>> # affects fmgridif.cxx and ColumnControl.cxx >>>>>> # See:<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65009> >>>>>> if [ ${CXX} = g++49 ]; then \ >>>>>> ${REINPLACE_CMD} -e "s/ := -Os/ := -Os >>>>>> -fno-devirtualize -fno-de >>>>>> virtualize-speculatively/" ${WRKSRC}/solenv/gbuild/platform/freebsd.mk; \ >>>>>> ${REINPLACE_CMD} -e "s/=-Os /=-Os -fno-devirtualize >>>>>> -fno-devirtu >>>>>> alize-speculatively /" ${WRKSRC}/solenv/inc/unxfbsdi.mk; \ >>>>>> fi >>>>>> >>>>>> >>>>>> For Linux you would have to patch main/solenv/gbuild/platform/linux.mk >>>>>> (and main/solenv/inc/unxlng*.mk for non-x86_64 platforms). >>>>> >>>>> I've add the following to line 152, beside to the COMPILERNOOPTSFLAFS >>>>> >>>>> gb_COMPILEROPTFLAGS := O0 >>>>> >>>>> I hope that this correct. If so, then unfortunately it doesn't make a >>>>> change. Stil lthe same error. >>>>> >>>>>> On x86_64, the Library_svxcore.mk patch should have done the trick >>>>>> though. The problem is triggered by using -Os optimization and with >>>>>> that change to Library_svxcore.mk, fmgridif.cxx should be getting >>>>>> compiled with -O0. Can you check the log file to see if that is the >>>>>> case? You'll probably have to configure with --enable-verbose to see >>>>>> it. >>>>> >>>>> OK, turned back the "linux.mk" patch. >>>>> >>>>> I've added --enable-verbose to configure, bootstrap'ed and source'ed >>>>> again. The build cancelled at the same location and with the same error >>>>> message. >>>>> >>>>> "fmgridif.cxx" was nowhere mentioned, only a "fmgridif.o". It's the last >>>>> file mentioned in a long list of .o files from module "svx". >>>> >>>> Are you starting from a clean build each time? If you just restart the >>>> build, it will reuse the bad fmgridif.o. It is necessary to recompile >>>> fmgridif.cxx with the patched Library_svxcore.mk. >>> >>> I always do a "build --prepare --from svx" before starting a new build. >>> I hope thats the right one. I don't find a "clean" or something else for >>> the "build" comamnd. >> >> Hmn, I wonder if --prepare does the right thing with gbuild ... >> >> Try blowing away solver/*.pro/workdir/CxxObject/svx. > > hm, maybe not. ;-) When I delete > "solver/420/*.pro/workdir/CxxObject/svx", then the build is now getting > further ... > > ... until dbaccess. From the end of the log file it seems that the > "ColumnControl.cxx" file hits the same compiler optimization problem. > Maybe stupid question but is this possible? If so, then I would expect > this also for more files that are still to come.
Yes, that is the other one, but on FreeBSD only intel is affected and not x86_64. Or, I should say was, because dbaccess just got converted from dmake to gbuild. On FreeBSD, x86_64 defaults to using -O2 for dmake modules and only the intel dmake modules build with -Os. The gbuild modules use -Os for both. You'll have to edit dbaccess/Library_dbui.mk. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
