Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Friday, December 07, 2007 8:56 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)

Farid Zaripov wrote:
Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc 3.4.4.
I get really nervous whenever we start to mess around with the runtime symbols, especially when changing which ones are exported on Windows and which ones aren't. Doesn't exporting just members and not the whole class have an impact on things like RTTI and exceptions? Have you tested it with the other Windows compilers (Intel C++ and MSVC)?

  Yes. The all examples and tests were compiled and runs as usual.

Also, I'm more than a little uncomfortable with hardcoding __CYGWIN__ all over the place. Isn't there a single file where we could tweak _RWSTD_NO_XXX_DEFAULT_CTOR et al macros?

  Ok, we can leave include/exception, include/new and include/typeinfo
header
files unchanged since in this patch _RWSTD_EXPORT macro is #defined to
/*empty*/
if _RWSTD_LIB_SRC macro is not #defined.

Finally, did you consider STDCXX-408 when enabling dllexport?

  Yes. Unfortunately I haven't access to the HP aCC 3.37
compiler/platform to test
how the library builts with the using the dllexport/import directives.

You could use one of the HP TestDrive servers ;-)
  http://www.testdrive.hp.com/

Seriously, what I was suggesting is to make the implementation
general enough to make it easy to extend to other compilers
besides gcc, such as aCC. One way to do it might be to replace
the preprocessor guard around _RWSTD_EXPORT in rw/_defs.h with
_RWSTD_NO_DLLEXPORT and add a config test to see if
__declspec(dll{ex,im}port) is supported.


  The gcc, as I commented in the issue, supports dllexport/dllimport
attributes
only on Cygwin and Symbian platforms.

Right, I saw your comment.

Martin

Reply via email to