openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Lewis <truck...@apache.org>
Subject Re: Help needed: Build error in bean and vcl
Date Mon, 05 Sep 2016 22:25:04 GMT
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message