From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Mon, 21.01.2008 21:09 To: [EMAIL PROTECTED] Subject: [PING] Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
> We never decided what to do with the patch. Farid, do you have any > feedback on the questions below? [...] >> 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). Right. > 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? I've tried to build stdcxx tests and examples without using __declspec (dllimport) and I've gor the linkr errors about unresolved external symbol. The all unresolved symbols are data symbols (not functions), i.e. __rw::__nullref, std::cout, std::cerr, ... So I can say, that MSVC supports auto-importing of the functions only. > 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++)... Maybe this is a good idea. >> 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? As I mentioned above the MSVC imports functions from DLL without declaring them as dllimport. But I suppose that this is undocumented feature. >> 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 meant not use the only dllimport and only on gcc/cygwin. > 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? We already have the _RWSTD_DLLIMPORT macro for this. Farid.
