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:57:37 GMT
Am 09/06/2016 12:25 AM, schrieb Don Lewis:
> 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.

OK, I'm way too impatient. I've patched also this makefile ...

... and now I got an installation package at the end. Good that I added 
a "--with-package-format="installed". So, starting is easy and fast. Now 
I've got a AOO 4.2.0m1 Build 9800 Rev. 1759138.

Hurrah :-)

Thank very much for your help. Of course, as a good contributor I'll 
collect all data and update [1] with a new Fedora 21 section.

[1] 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step

CU tomorrow

Marcus

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


Mime
View raw message