We never decided what to do with the patch. Farid, do you have any feedback on the questions below?
Martin Sebor wrote: > > Farid Zaripov wrote: >>> -----Original Message----- >>> From: Travis Vitek [mailto:[EMAIL PROTECTED] >>> Sent: Monday, December 10, 2007 7:25 PM >>> To: [EMAIL PROTECTED] >>> Subject: Re: [PATCH] STDCXX-507 (or using >>> __declspec(dllexport/dllimport on gcc/cygwin in shared builds) >>> >>>>> It seems that the problem is that the Cygwin environment >>> defines part >>>>> of the >>>>> C++ runtime library in the C library. >>>> It does? I don't see any such symbols in the localedef.imports file >>>> attached to STDCXX-507 (although there are a lot symbols there so I >>>> could have easily missed them). >>>> >>> Maybe I'm totally off base, but it appears that Farid is >>> trying to avoid exporting set_unexpected, unexpected, >>> set_terminate, terminate, uncaught_exception and the >>> exception types. Aren't all of these things from the support >>> library? >> >> These functions and also dtor() and what() members of the >> std::exception, std::bad_exception, std::bad_alloc, std::bad_cast, >> std::bad_typeid are defined in libsupc++.a. > > They *may be* defined there, right? I.e., most of them typically > are but some may not be (e.g.., bad_alloc ctors and assignment > operators don't seem to be). > > When our config tests determine they're not defined in the support > library, we define them in stdxxx. > > But even when they are defined in the runtime we still declare them > in our headers, which as Farid explains below seems to be a problem > when we use declspec(dllimport) and the runtime is an archive. > > What if we never used declspec(dllimport), even for runtime symbols > defined in the MSVC runtime DLL? Would that be a problem? > >> >>> Why would it help us to not export them? >> >> The using of the __declspec(dllimport) in declarations in client code >> appends the __imp__ prefix to the referenced symbol. >> I.e. for the set_terminate() function the referenced symbol name would >> be >> __imp__set_terminate (I'm not including the name mangling just for >> example). >> So the user will get a "undefined reference" linker errors. The MSVC >> doesn't >> have this problem because the we're using the shared libc in our shared >> library >> builds, so the symbol in MSVC libc will be also with __imp__ prefix. But >> libsupc++ >> library is present only as static library. > > It sounds like we might need a config test to determine if the C++ > runtime is defined in a DLL (MSVC) or in an archive (libsupc++)... > >> >> But now I see that we can leave the inlude/exception, include/new and >> include/typeinfo header files unchanged because the gcc/cygwin supports >> auto-importing feature (it's first searching "xxx" symbol name, then if >> the >> symbol is not found the "__imp__xxx" symbol will be searched). > > Aha! That would make it work for gcc. What about MSVC? Does it also > support auto-importing? > >> >> We just should define _RWSTD_EXPORT as /*empty*/ if the _RWSTD_LIB_SRC >> macro is not #defined. > > But that would prevent exporting our symbols too. Are you suggesting > we not use dllexport/dllimport with gcc on Windows at all? (Because > of auto-importing?) > > I suspect auto-importing comes at a price (since each symbol might > need to be looked up twice). If it does, it might make sense to > instead avoid declaring just the runtime symbols dllexported when > we know they are defined in the gcc runtime and keep dllexport > for our own symbols. Maybe we could do this by adding something > like _RWSTD_RUNTIME_EXPORT? > > Martin > >> >> Farid. > > > -- View this message in context: http://www.nabble.com/-PATCH--STDCXX-507-%28or-using-__declspec%28dllexport-dllimport-on-gcc-cygwin-in-shared-builds%29-tp14217944p15004164.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
