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