[PING] Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)

[Martin Sebor <se...@roguewave.com>]

We never decided what to do with the patch. Farid, do you have any
feedback on the questions below?


Martin Sebor wrote:
> 
> 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.
> 
> 
> 

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

Re: [PING] Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)

[Farid Zaripov <Fa...@epam.com>]

From: Martin Sebor [mailto:sebor@roguewave.com]
Sent: Mon, 21.01.2008 21:09
To: stdcxx-dev@incubator.apache.org
Subject: [PING] Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)

> We never decided what to do with the patch. Farid, do you have any
> feedback on the questions below?

[...]

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

> 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?
 
  I've tried to build stdcxx tests and examples without using __declspec (dllimport)
and I've gor the linkr errors about unresolved external symbol. The all unresolved
symbols are data symbols (not functions), i.e. __rw::__nullref, std::cout, std::cerr, ...
So I can say, that MSVC supports auto-importing of the functions only.

> 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++)...
 
  Maybe this is a good idea.

>>   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?
  As I mentioned above the MSVC imports functions from DLL without
declaring them as dllimport. But I suppose that this is undocumented feature.

>>   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 meant not use the only dllimport and only on gcc/cygwin.

> 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?
 
  We already  have the _RWSTD_DLLIMPORT macro for this.

Farid.