When building openoffice-devel with gcc 4.9, the build fails with these errors:
/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdi.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: In function `FmXGridControl::createPeer(com::sun::sta r::uno::Reference<com::sun::star::awt::XToolkit> const&, com::sun::star::uno::Reference<com::sun::star::awt::XWindowPeer> const&)': fmgridif.cxx:(.text+0x6f31): undefined reference to `non-virtual thunk to WindowListenerMultiplexer::acquire()' fmgridif.cxx:(.text+0x6f7d): undefined reference to `non-virtual thunk to FocusListenerMultiplexer::acquire()' fmgridif.cxx:(.text+0x6fc9): undefined reference to `non-virtual thunk to KeyListenerMultiplexer::acquire()' fmgridif.cxx:(.text+0x7015): undefined reference to `non-virtual thunk to MouseListenerMultiplexer::acquire()' fmgridif.cxx:(.text+0x7061): undefined reference to `non-virtual thunk to MouseMotionListenerMultiplexer::acquire()' fmgridif.cxx:(.text+0x70ad): undefined reference to `non-virtual thunk to PaintListenerMultiplexer::acquire()' collect2: error: ld returned 1 exit status /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/gbuild/LinkTarget.mk:259: recipe for target '/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/42 0/unxfbsdi.pro/workdir/LinkTarget/Library/libsvxcore.so' failed gmake: *** [/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdi.pro/workdir/LinkTarget/Library/libsvxcore.so] Error 1 gmake: *** Waiting for unfinished jobs.... rm /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdi.pro/workdir/ExternalHeaders/Library/libxcr.so dmake: Error code 2, while making 'all'
I found this discussion by the LibreOffice folks:
https://www.mail-archive.com/blfs-support@lists.linuxfromscratch.org/msg00910.html
which leads to this patch:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb182b47ca7362b05c03d583d3547643d9a99562
which changes a header file so that it is supposed to mark methods of the classes in question to
be published.
Unfortunately this does not work. I ran an elfdump -s on the library .so file that contains these symbols.
and found that they are flagged as STB_FUNC STB_LOCAL. The patch changes the other methods for these classes
to be STB_GLOBAL, but does not seem to effect the aquire and release methods. If I run nm on the .o file
that contains these symbols, the are of type W instead of type T.
000028d8 T _ZN22KeyListenerMultiplexer10keyPressedERKN3com3sun4star3awt8KeyEventE 00002aa6 T _ZN22KeyListenerMultiplexer11keyReleasedERKN3com3sun4star3awt8KeyEventE 000005b4 T _ZN22KeyListenerMultiplexer14queryInterfaceERKN3com3sun4star3uno4TypeE 00000000 W _ZN22KeyListenerMultiplexer7acquireEv 00000000 W _ZN22KeyListenerMultiplexer7releaseEv 00000038 T _ZN22KeyListenerMultiplexer9disposingERKN3com3sun4star4lang11EventObjectE
Digging further into the code, there are some macros that are used in the header file
that is being patched:
#define DECL_LISTENERMULTIPLEXER_START( ClassName, InterfaceName ) \
class ClassName : public ListenerMultiplexerBase, public InterfaceName \
{ \
public: \
ClassName( ::cppu::OWeakObject& rSource ); \
::com::sun::star::uno::Any SAL_CALL queryInterface( const ::com::sun::star::uno::Type & rType ) throw(::com::sun::star::uno::RuntimeException); \
void SAL_CALL acquire() throw() { ListenerMultiplexerBase::acquire(); } \
void SAL_CALL release() throw() { ListenerMultiplexerBase::release(); } \
void SAL_CALL disposing( const ::com::sun::star::lang::EventObject& Source ) throw(::com::sun::star::uno::RuntimeException);vs.
#define DECL_LISTENERMULTIPLEXER_START_DLLPUB( ClassName, InterfaceName ) \
class TOOLKIT_DLLPUBLIC ClassName : public ListenerMultiplexerBase, public InterfaceName \
{ \
public: \
ClassName( ::cppu::OWeakObject& rSource ); \
::com::sun::star::uno::Any SAL_CALL queryInterface( const ::com::sun::star::uno::Type & rType ) throw(::com::sun::star::uno::RuntimeException); \
void SAL_CALL acquire() throw() { ListenerMultiplexerBase::acquire(); } \
void SAL_CALL release() throw() { ListenerMultiplexerBase::release(); } \
void SAL_CALL disposing( const ::com::sun::star::lang::EventObject& Source ) throw(::com::sun::star::uno::RuntimeException);As near as I can tell, TOOLKIT_DLLPUBLIC gets expanded to attribute ((visibility("default"))),
assuming HAVE_GCC_VISIBILITY_FEATURE.
The patch changes a number of the classes to use DECL_LISTENERMULTIPLEXER_START_DLLPUB instead
of DECL_LISTENERMULTIPLEXER_START, for instance this one:
// ----------------------------------------------------
// class KeyListenerMultiplexer
// ----------------------------------------------------
DECL_LISTENERMULTIPLEXER_START( KeyListenerMultiplexer, ::com::sun::star::awt::XKeyListener )
void SAL_CALL keyPressed( const ::com::sun::star::awt::KeyEvent& e ) throw(::com::sun::star::uno::RuntimeException);
void SAL_CALL keyReleased( const ::com::sun::star::awt::KeyEvent& e ) throw(::com::sun::star::uno::RuntimeException);
DECL_LISTENERMULTIPLEXER_ENDThe patch changes the keyPressed, keyReleased, and queryInterface from STB_LOCAL to STB_GLOBAL,
but acquire and release are unaffected.
I also found this trouble ticket: http://wiki.linuxfromscratch.org/blfs/ticket/5042
which has a different approach to fixing the problem. In this ticket, the problem appears
to only happen on i386 and not amd64, so they wrap the problematical calls in a
#ifndef i386 / #endif wrapper so they don't get compiled on i386. The build
succeeds, but that seems to be the wrong approach. I would worry that the resulting
executable would not operate properly.
I decided to use the first approach. The LibreOffice patch does not apply cleanly,
so I applied it by hand. Then I augmented this patch by adding TOOLKIT_DLLPUBLIC
to the declaration of the acquire and release methods. That allows the build
to succeed.
After testing is completed, I will change the value USE_GCC from 4.9 to yes.