> -----Original Message----- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Monday, December 10, 2007 7:25 PM > To: stdcxx-dev@incubator.apache.org > 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. > 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. 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). We just should define _RWSTD_EXPORT as /*empty*/ if the _RWSTD_LIB_SRC macro is not #defined. Farid.
