cp->hr: I think this is less of a toolkit issue but requires more of
an gcc expert. Can you comment on the problem resp. check with MT what
needs to be done ?

Hi, 
 
Just to add:   as long as this does not indicate some other 
more serious probem, this is is not a showstopper at all for me.

I was able to cleanly build all of OOo 1.1 Beta 2 once I 
added the -fno-rtti switch for the complete build. 
 
I just don't understand C++ well enough to understand what is so
special about the IComboListBoxHelper class that prevents gcc from
creating the proper runtime type info it seems to need.  

This is the only class in the entire OOo build that seems to have this 
problem so I was hoping someone more experienced with C++ could give
me a hint as to what to look at. 
 
I am going to reduce the priority of this way down, since I can make a
clean build by adding -fno-rtti. 
 
Thanks for any hints or advice. 
 
Kevin 

I have troubles getting past this as well.

This is the error message I see:

------------------------------
Making Module-Definitionfile : ../unxirgm.pro/misc/tk644im.def
just a dummy for UNIX
ld32: WARNING 84 : /usr/lib32/libpthread.so is not used for resolving
any symbol.
ld32: WARNING 84 :
/usr/local/gcc-2.95.3/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/libgcc.a is
not used for resolving any symbol.
ld32: WARNING 84 :
/usr/local/gcc-2.95.3/lib/gcc-lib/mips-sgi-irix6.5/2.95.3/libstdc++.a
is not used for resolving any symbol.
ld32: WARNING 157: Unresolved text symbol
"toolkit::IComboListBoxHelper type_info function" -- 1st referenced by
../unxirgm.pro/slo/vclxaccessiblelist.o.
        Use linker option -v to see when and which objects, archives
and dsos are loaded.  
ld32: WARNING 157: Unresolved text symbol
"toolkit::IComboListBoxHelper type_info node" -- 1st referenced by
../unxirgm.pro/slo/vclxaccessiblelist.o.
        Use linker option -v to see when and which objects, archives
and dsos are loaded.  
Checking DLL ../unxirgm.pro/lib/check_libtk644im.so ...: ERROR:
37026:/oowp/beta2/workarea/solver/644/unxirgm.pro/bin/checkdll: rld:
Fatal Error: unresolvable symbol in
../unxirgm.pro/lib/check_libtk644im.so:
__tfQ27toolkit19IComboListBoxHelper
dmake:  Error code 1, while making '../unxirgm.pro/lib/libtk644im.so'

ERROR: Error 65280 occurred while making /oowp/beta2/workarea/toolkit/util
---* TG_SLO.MK *---

Unfortunately, we cant build OO with -no-rtti on IRIX.
Anyone suggest another possible workaround?

Sorry, edit that last post, we CAN build with -fno-rtti, it is the
other way around.... meaning we CANT build with -frtti

So now I gotta start all over again.... *sigh*

Set to target Milestone OOo 1.1 RC

I can confirm that the same bug breaks the FreeBSD port of
1.1Beta2 on FreeBSD.

Martin

The issue here is the mixture of rtti and no-rtti.  More than likely 
when the particular element is built it is build explicitly with no-
rtti and when the module that links is built it is *defaulting* to 
rtti.  The solution is fairly simple figure out where this module is 
compiled and remove the explicit no-rtti and see if it breaks both 
types of build.  This will be a constant problem until we decide that 
we use one or the other as a default.  The rtti code adds a few meg 
to the download and perhaps slows down the application for no real 
benefit.  Can't we just standardise?

Kevin, George, Ken

I'm not sure if anyone uses dynamic_cast, but if not, everything
should be compiled with fno-rtti, because it buys us nothing. GCC is
smart enough to create RTTI information if it's needed for exception
handling even with RTTI switched of.

If this doesn't work with your GCC version than just switch RTTI on.
The difference is not that huge.

Kevin, I reassign this one back to you since this is just an issue
with either building everything with or without RTTI. BTW since is a
Prio 5 task shouldn't we target it to OOo 2.0?

 

Hi, 
 
Actually, I don't think this is a mixing issue at all. 
PPC Linux used to force the build with -frtti and I grepped the entire source and 
outside of the mozilla addressbook libraries (which have nothing to do with this 
issue),  there were -fno-rtti switches. 
 
If you look in the reverse there are some -frtti switches in some of the module 
makefiles so since the last switch controls things, any mixing will come from building 
with nothing or with -fno-rtti in your solenv. 
 
I did examine this case in great detail when I first ran  into the problem and the library 
itself that contains the IComboListBoxHelper source itsled is the one that wont pass 
checkdll. 
 
Recompiling this module with neither -frtti nor -fno-rtti does not work either. 
 
So this problem is that something in the IComboListBoxHelper source confuses the 
compiler and it fails to build the proper runtime type information is needs.  This file 
must be compiled with -fno-rtti which is probably indicative of a bug in gcc or the 
source. 
 
Kevin 
 

HR->OJ: IComboBoxHelper has three virtual methods which are neither
pure virtual nor implemented somewhere. This leads to the need for a
RTTI symbol for IComboBoxHelper in vclxaccesiblelist.cxx on some
versions of GCC which is unresolved since there is nowhere an
implementation of IComboBoxHelper. We need either a dummy
implementation or a *all* methods have to be pure virtual. Please fix ...

HR->KHENDRICKS: reassigning to OJ

Hi, 
 
Martin Blapp (FreeBSD) tested a fix based on Heiner's and Chris's explanation of 
what was causing the problem, and he said it worked. 
 
So for the record I am posting his message /patch here just in case it helps. 
 
Date: Wed Jun 4 01:40:00 2003 
From: Martin Blapp <mb@imp.ch> 
To: dev@porting.openoffice.org, "" <Jens-Heiner.Rechtien@Sun.COM> 
Reply to: dev@porting.openoffice.org 
 
Hi, 
 
Yes it seems you were both correct. This patch solved it for me: 
 
--- ../toolkit/inc/toolkit/helper/IComboListBoxHelper.hxx.orig  Wed May  7 11:05:11 
2003 
+++ ../toolkit/inc/toolkit/helper/IComboListBoxHelper.hxx       Wed Jun  4 00:07:03 
2003 
@@ -103,10 +103,10 @@ 
                virtual void                    SetNoSelection() = 0; 
                virtual USHORT                  GetSelectEntryPos( USHORT nSelIndex = 0 ) 
const = 0; 
                virtual BOOL            IsInDropDown() const = 0; 
-        virtual Rectangle       GetEntryCharacterBounds( const sal_Int32 
_nEntryPos, const sal_Int32 _nCharacterIndex ) const; 
-        virtual long            GetIndexForPoint( const Point& rPoint ) const; 
-        virtual ::com::sun::star::uno::Reference< 
::com::sun::star::datatransfer::clipboard::XClipboard > 
-                                GetClipboard(); 
+               virtual Rectangle       GetEntryCharacterBounds( const sal_Int32 
_nEntryPos, const sal_Int32 _nCharacterIndex )  { } const ; 
+               virtual long            GetIndexForPoint( const Point& rPoint ) { } const ; 
+               virtual ::com::sun::star::uno::Reference< 
::com::sun::star::datatransfer::clipboard::XClipboard > 
+               GetClipboard() { } ; 
        }; 
 } 
 #endif // TOOLKIT_HELPER_COMBOLISTBOXHELPER_HXX 
 
Martin 
 

pointed to this because Ocke is on vacation ....

I know very little 'bout this interface, but from the little I know,
and from looking at it's use cases, it seems that there was some ...
lazyness involved originally. No implementation is required for these
method.

I suggest making them pure virtual, instead of the fix suggested above
- simply because of the "Inline Virtual Is Evil" (TM) paradigm.

Additionally, implementing them empty only generates unnecessary
symbols (on all platforms, probably), which unnecessarily pollutes the
namespace, (slightly) increases library load time, and such (let's
stop the beginning on such things :)

Kevin, could you do this change (making them pure virtual), and check
this in, please?

Hi, 
 
Okay. I have made the change and I am rebuilding toolkit with -frtti just to check. 
Assuming all is well I will check this into cws_srx644_ooo11beta2 citing this issue. 
 
I will then resolve this as fixed after the test and commit. 
 
Thanks, 
 
Kevin 
 

Hi, 
 
Arrgghh!  To check this properly, I will need to rebuild the whole OOo with -frtti since 
my latest build was made with -fno-rtti to work around this very issue! 
 
Without a rebuild with -frtti, some of the support libs not built with -frtti result in new 
missing symbols ... 
 
Checking DLL ../unxlngppc.pro/lib/check_libtk644lp.so ...: ERROR: 
../unxlngppc.pro/lib/check_libtk644lp.so: undefined symbol: 
_ZTIN10comphelper34OAccessibleExtendedComponentHelperE 
dmake:  Error code 1, while making '../unxlngppc.pro/lib/libtk644lp.so' 
---* TG_SLO.MK *--- 
 
ERROR: Error 65280 occurred while making /src2/ooo11b2/toolkit/util 
 
So checking this will take some time.  
 
Kevin 
 

Kevin, I have verified this, it worked fine for me!
I will include my patch as well (even though you dont need it)

Created attachment 6694 [details]
patch for toolkit/inc/toolkit/helper/IComboListBoxHelper.hxx as used on Irix Port

Hi George, 
 
Thanks for testing it and your patch.  I have just commited it to 
cws_srx644_ooo11beta2 so I am now resolving this as fixed and then closing it 
since you have already verified it. 
 
Thanks, 
 
Kevin 
 
 
 

setting to fixed 

marking issue as closed since build error fix was already verified