You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/10/18 22:50:35 UTC
binary compatibility question
The binary compatibility requirement is related to shared libraries only,
or to both shared and static libraries?
If only to shared libraried, then the STDCXX-509 issue can be fixed
on MSVC by exporting alias with the required name using /EXPORT
linker option.
Farid.
Re: binary compatibility question
Posted by Martin Sebor <se...@roguewave.com>.
Farid, I'm afraid your patch got stripped -- can you try again,
maybe inline?
Martin
Farid Zaripov wrote:
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Пт, 19.10.2007 0:35
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: binary compatibility question
>>
>
> [...]
>
>> So what would we do in the archive? Keep the incompatible extern "C" symbol?
>
> Yes. Actually in shared library will be present both extern C" and extern "C++" constants.
> I've tried to export the extern "C" _xxxBits constants, but the alias names were stripped up
> to th first '@' character, i.e. the following directive
>
> #pragma comment (linker, "/EXPORT:?__rw_flt_qNaN@__rw@@3MB=__rw_flt_qNaN,DATA")
>
> exported "?__rw_flt_qNaN" symbol instead of "?__rw_flt_qNaN@__rw@@3MB"
>
> So I've created another xxx_vc constants with C++ linkage and exported them.
>
>> It would be great if you could put together a patch.
>
> The patch is attached.
>
> ChangeLog:
> STDCXX-509
> * limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
> The _xxxBits constants defined with C++ linkage and exported as the floating
> constants with the mangled names for the binary compatibility with the stdcxx 4.1.x
>
> I see that the proper symbols are exported, but I can't check the 4.1.3 examples on MSVC 7.1
> at the moment (I'm writing from the home right now and no MSVC 7.1 here). Maybe some of You
> would test this patch (Martin, Travis)? Otherwise I'll test the patch tomorrow.
>
> Farid.
>
Re: binary compatibility question
Posted by Martin Sebor <se...@roguewave.com>.
Travis Vitek wrote:
>
>
> Farid Zaripov wrote:
>> Since the patch was stripped, I"m sending it inplace.
>>
>> ChangeLog:
>> STDCXX-509
>> * limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
>> The _xxxBits constants defined with C++ linkage and exported
>> as the floating constants with the mangled names for the binary
>> compatibility with the stdcxx 4.1.x
>>
>>
>
> Much cleaner that what I've provided, and it works to boot! Thank you
> Farid!
I like it a lot, too. I tested it with MSVC 7.1, it links and works,
with both kinds of symbols (the new and improved extern "C" ones for
new programs as well as the 4.1.3 compatibility set for existing
programs upgrading to 4.2.0) in the library.
Committed thus: http://svn.apache.org/viewvc?rev=586193&view=rev
Thanks!
Martin
RE: binary compatibility question
Posted by Travis Vitek <Tr...@roguewave.com>.
Farid Zaripov wrote:
>
> Since the patch was stripped, I"m sending it inplace.
>
> ChangeLog:
> STDCXX-509
> * limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
> The _xxxBits constants defined with C++ linkage and exported
> as the floating constants with the mangled names for the binary
> compatibility with the stdcxx 4.1.x
>
>
Much cleaner that what I've provided, and it works to boot! Thank you
Farid!
Re: binary compatibility question
Posted by Farid Zaripov <Fa...@epam.com>.
> The patch is attached.
Since the patch was stripped, I"m sending it inplace.
ChangeLog:
STDCXX-509
* limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
The _xxxBits constants defined with C++ linkage and exported as the floating
constants with the mangled names for the binary compatibility with the stdcxx 4.1.x
-------------------------
Index: limits_bits.cpp
===================================================================
--- limits_bits.cpp (revision 586084)
+++ limits_bits.cpp (working copy)
@@ -157,6 +157,74 @@
} // extern "C"/"C++"
+# if _RWSTD_VER_MAJOR < 5 && defined (_MSC_VER) && defined (_DLL)
+
+// The constants below are defined with C++ linkage
+// to be exported as floating constants with mangled
+// names for the binary compatibility with the stdcxx 4.1.x
+
+extern const _FltBits
+__rw_flt_infinity_vc = { _RWSTD_FLT_INF_BITS };
+
+extern const _FltBits
+__rw_flt_qNaN_vc = { _RWSTD_FLT_QNAN_BITS };
+
+extern const _FltBits
+__rw_flt_sNaN_vc = { _RWSTD_FLT_SNAN_BITS };
+
+extern const _FltBits
+__rw_flt_denorm_min_vc = { _RWSTD_FLT_DENORM_MIN_BITS };
+
+
+extern const _DblBits
+__rw_dbl_infinity_vc = { _RWSTD_DBL_INF_BITS };
+
+extern const _DblBits
+__rw_dbl_qNaN_vc = { _RWSTD_DBL_QNAN_BITS };
+
+extern const _DblBits
+__rw_dbl_sNaN_vc = { _RWSTD_DBL_SNAN_BITS };
+
+extern const _DblBits
+__rw_dbl_denorm_min_vc = { _RWSTD_DBL_DENORM_MIN_BITS };
+
+
+# ifndef _RWSTD_NO_LONG_DOUBLE
+
+extern const _LDblBits
+__rw_ldbl_infinity_vc = { _RWSTD_LDBL_INF_BITS };
+
+extern const _LDblBits
+__rw_ldbl_qNaN_vc = { _RWSTD_LDBL_QNAN_BITS };
+
+extern const _LDblBits
+__rw_ldbl_sNaN_vc = { _RWSTD_LDBL_SNAN_BITS };
+
+extern const _LDblBits
+__rw_ldbl_denorm_min_vc = { _RWSTD_LDBL_DENORM_MIN_BITS };
+
+# endif // _RWSTD_NO_LONG_DOUBLE
+
+
+# pragma comment (linker, "/EXPORT:?__rw_flt_infinity@__rw@@3MB=?__rw_flt_infinity_vc@__rw@@3T_FltBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_flt_qNaN@__rw@@3MB=?__rw_flt_qNaN_vc@__rw@@3T_FltBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_flt_sNaN@__rw@@3MB=?__rw_flt_sNaN_vc@__rw@@3T_FltBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_flt_denorm_min@__rw@@3MB=?__rw_flt_denorm_min_vc@__rw@@3T_FltBits@1@B,DATA")
+
+# pragma comment (linker, "/EXPORT:?__rw_dbl_infinity@__rw@@3NB=?__rw_dbl_infinity_vc@__rw@@3T_DblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_dbl_qNaN@__rw@@3NB=?__rw_dbl_qNaN_vc@__rw@@3T_DblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_dbl_sNaN@__rw@@3NB=?__rw_dbl_sNaN_vc@__rw@@3T_DblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_dbl_denorm_min@__rw@@3NB=?__rw_dbl_denorm_min_vc@__rw@@3T_DblBits@1@B,DATA")
+
+# ifndef _RWSTD_NO_LONG_DOUBLE
+# pragma comment (linker, "/EXPORT:?__rw_ldbl_infinity@__rw@@3OB=?__rw_ldbl_infinity_vc@__rw@@3T_LDblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_ldbl_qNaN@__rw@@3OB=?__rw_ldbl_qNaN_vc@__rw@@3T_LDblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_ldbl_sNaN@__rw@@3OB=?__rw_ldbl_sNaN_vc@__rw@@3T_LDblBits@1@B,DATA")
+# pragma comment (linker, "/EXPORT:?__rw_ldbl_denorm_min@__rw@@3OB=?__rw_ldbl_denorm_min_vc@__rw@@3T_LDblBits@1@B,DATA")
+# endif // _RWSTD_NO_LONG_DOUBLE
+
+#endif // _RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL
+
#else // if defined (_RWSTD_NO_INFINITY)
-------------------------
Farid.
Re: binary compatibility question
Posted by Farid Zaripov <Fa...@epam.com>.
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Пт, 19.10.2007 0:35
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: binary compatibility question
>
[...]
> So what would we do in the archive? Keep the incompatible extern "C" symbol?
Yes. Actually in shared library will be present both extern C" and extern "C++" constants.
I've tried to export the extern "C" _xxxBits constants, but the alias names were stripped up
to th first '@' character, i.e. the following directive
#pragma comment (linker, "/EXPORT:?__rw_flt_qNaN@__rw@@3MB=__rw_flt_qNaN,DATA")
exported "?__rw_flt_qNaN" symbol instead of "?__rw_flt_qNaN@__rw@@3MB"
So I've created another xxx_vc constants with C++ linkage and exported them.
> It would be great if you could put together a patch.
The patch is attached.
ChangeLog:
STDCXX-509
* limits_bits.cpp [_RWSTD_VER_MAJOR < 5 && _MSC_VER && _DLL]:
The _xxxBits constants defined with C++ linkage and exported as the floating
constants with the mangled names for the binary compatibility with the stdcxx 4.1.x
I see that the proper symbols are exported, but I can't check the 4.1.3 examples on MSVC 7.1
at the moment (I'm writing from the home right now and no MSVC 7.1 here). Maybe some of You
would test this patch (Martin, Travis)? Otherwise I'll test the patch tomorrow.
Farid.
Re: binary compatibility question
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
> The binary compatibility requirement is related to shared libraries only,
> or to both shared and static libraries?
Both.
When the user builds their own shared library, libusr.so, from
the stdcxx archive, libstd.a, (a subset of) stdcxx symbols become
part of the interface of libusr.so. When libusr.so is linked into
an executable that also links with libstd.a, the stdcxx symbols
compiled into the common interface between the two parts of the
executable must be compatible with one another.
The issue becomes a little bit more complicated when it comes to
implementation details like the __rw_dbl_infinity symbol that's
not really part of the interface to begin with and can't easily
become one, if at all. On Windows, AFAIK, these details become
private to each module (i.e., libusr.so will have its own copy
and so will the executable).
>
> If only to shared libraried, then the STDCXX-509 issue can be fixed
> on MSVC by exporting alias with the required name using /EXPORT
> linker option.
So what would we do in the archive? Keep the incompatible extern
"C" symbol? I can't really think of a problem with that. Travis,
can you?
It would be great if you could put together a patch.
Martin
RE: binary compatibility question
Posted by Farid Zaripov <Fa...@epam.com>.
> От: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
> Отправлено: Пт, 19.10.2007 0:07
> Кому: stdcxx-dev@incubator.apache.org
> Тема: RE: binary compatibility question
>
> Farid Zaripov wrote:
> >
> > The binary compatibility requirement is related to shared
> >libraries only, or to both shared and static libraries?
> >
>
> Well technically it is a problem with both static and shared, but for it
> to be an issue with a static build the user would have to have kept
> their object files laying around, otherwise they would just rebuild the
> entire app. Right?
Yes.
>
> > If only to shared libraried, then the STDCXX-509 issue can be fixed
> >on MSVC by exporting alias with the required name using /EXPORT
> >linker option.
> >
>
> Yes, this was mentioned in the status call on Wednesday. The idea was
> discarded because it seems it would require some changes to the build
> infrastructure.
No changes ar required in build infrastructure, because of we can use
#pragma comment (linker, "") dirctive (see the src/export.cpp file).
I.e. #pragma commnt (linker, "/EXPORT:?__rw_flt_infinity@__rw@@3MB=?__rw_flt_infinity@__rw@@3T_FltBits@1@B,DATA")
for __rw_flt_infinity and so on.
Farid.
RE: binary compatibility question
Posted by Travis Vitek <Tr...@roguewave.com>.
Farid Zaripov wrote:
>
> The binary compatibility requirement is related to shared
>libraries only, or to both shared and static libraries?
>
Well technically it is a problem with both static and shared, but for it
to be an issue with a static build the user would have to have kept
their object files laying around, otherwise they would just rebuild the
entire app. Right?
> If only to shared libraried, then the STDCXX-509 issue can be fixed
>on MSVC by exporting alias with the required name using /EXPORT
>linker option.
>
Yes, this was mentioned in the status call on Wednesday. The idea was
discarded because it seems it would require some changes to the build
infrastructure.
>Farid.
>
>