From: Al S. <al....@sc...> - 2002-02-21 08:40:37
|
Is this problem only with throwing const char* exceptions? Or is the problem throwing built in types? My test case works fine if I throw stl strings. Al > -----Original Message----- > From: min...@li... > [mailto:min...@li...]On Behalf Of > Danny Smith > Sent: 21 February 2002 08:31 > To: al....@sc...; Min...@li... > Subject: RE: [Mingw-users] mingw32 DLLs, threads and exceptions HOWTO > (Update) > > > --- Danny Smith <dan...@ya...> wrote: > > --- Al Slater > <al....@sc...> wrote: > Does anyone have any input > > to > > this, I am going nuts trying to figure it > > > out. > > > > > No your not going nuts. Its a real bug. I'll play with it > tonight. The > > problem seems that to be with the ctor for the const char* > exception obj, > > which gets pulled in from libgcc.a rather than from the dll. > > > > Thanks for sending the useful testcase. > > > > Danny > > > No, it is a problem with dllimport of data symbols. > These symbols from libgcc.a (in tinfo2.o) are exported from the dll: > > __ti10bad_typeid @ 114 DATA ; bad_typeid type_info node > __ti13bad_exception @ 115 DATA ; bad_exception type_info node > __ti14__si_type_info @ 116 DATA ; __si_type_info type_info node > __ti16__attr_type_info @ 117 DATA ; __attr_type_info > type_info node > __ti16__func_type_info @ 118 DATA ; __func_type_info > type_info node > __ti16__ptmd_type_info @ 119 DATA ; __ptmd_type_info > type_info node > __ti16__ptmf_type_info @ 120 DATA ; __ptmf_type_info > type_info node > __ti16__user_type_info @ 121 DATA ; __user_type_info > type_info node > __ti17__array_type_info @ 122 DATA ; __array_type_info > type_info node > __ti17__class_type_info @ 123 DATA ; __class_type_info > type_info node > __ti19__builtin_type_info @ 124 DATA ; > __builtin_type_info type_info node > __ti19__pointer_type_info @ 125 DATA ; > __pointer_type_info type_info node > __ti8bad_cast @ 126 DATA ; bad_cast type_info node > __ti9bad_alloc @ 127 DATA ; bad_alloc type_info node > __ti9exception @ 128 DATA ; exception type_info node > __ti9type_info @ 129 DATA ; type_info type_info node > __tiSc @ 130 DATA ; signed char type_info node > __tiUc @ 131 DATA ; unsigned char type_info node > __tiUi @ 132 DATA ; unsigned int type_info node > __tiUl @ 133 DATA ; unsigned long type_info node > __tiUs @ 134 DATA ; unsigned short type_info node > __tiUx @ 135 DATA ; unsigned long long type_info node > __tib @ 136 DATA ; bool type_info node > __tic @ 137 DATA ; char type_info node > __tid @ 138 DATA ; double type_info node > __tif @ 139 DATA ; float type_info node > __tii @ 140 DATA ; int type_info node > __til @ 141 DATA ; long type_info node > __tir @ 142 DATA ; long double type_info node > __tis @ 143 DATA ; short type_info node > __tiv @ 144 DATA ; void type_info node > __tiw @ 145 DATA ; wchar_t type_info node > __tix @ 146 DATA ; long long type_info node > > Your dll tries to import those as the ordinary names above. > However, they > are DATA symbols and are only exported with _imp_ prefix in > the import lib. > Ld can't find the unprefixed name there so it looks in the > next libs. It > finds them in libgcc.a. But because it gets the typeinfo nodes from > tinfo2.o in libgcc.a it gets the other symbols needed to > build the rtti > for your exception object from there as well. Those symbols are the > duplicates that cause the error. > > Okay, one workaround may be to put tinfo2.o and tinfo.o in > libmingwthrd.a > as static objects- ie add them to the import lib with ar > after building the > dll part of the import lib. (They have to be included in the > dll as well > since other internal code depends on them. They don't *have* to be > exported, but that means hand-crafting the def file.). That > worked for you > testcase, but I haven't done any other testing. > > Welcome to the wild and crazy world of windows shared libraries. > > Danny > > http://movies.yahoo.com.au - Yahoo! Movies > - Vote for your nominees in our online Oscars pool. > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |