stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Date Fri, 07 Dec 2007 22:00:33 GMT
Travis Vitek wrote:
> 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,

You're more of an expert than me :)

> and I have zero experience with the Cygwin
> environment.

That's okay. I'm just looking for a second pair of eyes to help
review the patch in general.

> 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).


> 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 raw message