openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <marcus.m...@wtnet.de>
Subject Re: Help needed: Build error in bean and vcl
Date Mon, 05 Sep 2016 22:16:14 GMT
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.

I'll try to fix this tomorrow and report back.

Marcus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message