stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Date Mon, 10 Dec 2007 21:16:37 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Travis Vitek [mailto:vitek@roguewave.com] 
>> 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.

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

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?

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

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

> 
>   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?

> 
>   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 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?

Martin

> 
> Farid.


Mime
View raw message