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