incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Vitek <vi...@roguewave.com>
Subject Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Date Fri, 07 Dec 2007 20:06:44 GMT



Martin Sebor wrote:
> 
> 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)?
> 
> 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?
> 
> Finally, did you consider STDCXX-408 when enabling dllexport?
> 
> Travis, as the other Windows expert, can you take a look at Farid's
> patch and let us know what you think?
> 

I'm definitely no windows expert, and I have zero experience with the Cygwin
environment.

It seems that the problem is that the Cygwin environment defines part of the
C++ runtime library in the C library. This sounds like the issue that was
had with the VisualAge C++ compiler. Is this actually the case, or is there
some other C library that we can link to, or maybe a compile/link flag, that
allows us to avoid this problem?

Travis
-- 
View this message in context: http://www.nabble.com/-PATCH--STDCXX-507-%28or-using-__declspec%28dllexport-dllimport-on-gcc-cygwin-in-shared-builds%29-tf4963676.html#a14219694
Sent from the stdcxx-dev mailing list archive at Nabble.com.


Mime
View raw message