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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
