stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <tvi...@roguewave.com>
Subject RE: STDCXX-509
Date Wed, 17 Oct 2007 20:48:37 GMT

Forwarding private conversation to the list...



Farid,

While investigating solutions for STDCXX-509 we've run into some
compatibility issues with 4.2.0 that we could use your help to
track down.

Can you please run all stdcxx 4.1.3 examples with the 4.2.0 dll
on Windows (MSVC 7.1, 12d and 15d) and put together a list of
binary compatibility problems between the two libraries and post
it to the list?

Also, if you have any time left and can put together patches for
the problems, ideally guarded for MSVC (and Intel C++ on Windows)
only, that would be fantastic. Only if we can fix all or most of
the problems; if even one of the problems remains that makes the
whole library unusable from a binary compatibility standpoint,
there's no reason to spend time on it. We might as well say that
the library isn't binary compatible on Windows. Since we've
changed the name of the library, it shouldn't be a huge deal.

Thanks
Martin

Travis Vitek wrote:
> 
> Martin,
> 
> I don't know how you were able to run the 4.1.3 examples with the
4.2.0
> dll in place, but it most definitely does not work. You may not have
> noticed, but the dll name has changed. It used to be stdlib15d.dll and
> it has become libstd15d.dll. If you didn't rename the dll you dropped
> into the examples directory that might explain the problems you were
> having.

I renamed the DLL in my tests but I only tested the limits example.

> 
> Anyway, there are a few obvious binary compatibility issues that I ran
> into. Here are the test names and the undefined symbol that I get when
I
> run them against the new dll. Note that everything was built with
> msvc-7.1.
> 
>   limits.exe  : ?__rw_dbl_infinity@__rw@@3NB
>   codecvt.exe : ??0__rw_facet@__rw@@QAE@I@Z
>   ifstream.exe: ??0exception@@QAE@ABV0@@Z
> 
> Here are the undecorated names which can be retrieved with the
'undname'
> utility.
> 
>   limits.exe  : double const __rw::__rw_dbl_infinity
>   codecvt.exe : public: __thiscall
__rw::__rw_facet::__rw_facet(unsigned
> int)
>   ifstream.exe: public: __thiscall exception::exception(class
exception
> const &)
> 
> I wrote a quick script to take the list of symbols defined in the
4.1.3
> library and compare it to the symbols in the 4.2.0 library and compare
> them. This is the list of missing symbols. I believe they are all
binary
> compatibility issues, but I'm not absolutely sure they will cause
> failures. I tested a few of them, and the ones I tried did cause
> problems.
> 
>   public: __thiscall __rw::__rw_facet::__rw_facet(unsigned int)

Changed from public to protected (otherwise benign and not detected
by UNIX compilers):
   http://svn.apache.org/viewvc?view=rev&revision=554070

>   public: __thiscall bad_cast::bad_cast(class bad_cast const &)
>   public: __thiscall bad_typeid::bad_typeid(class bad_typeid const &)
>   public: __thiscall exception::exception(class exception const &)
>   public: __thiscall exception::exception(void)

No idea what this is about.

>   public: virtual __thiscall __rw::__rw_facet::~__rw_facet(void)

Changed from public to protected (same as above):
   http://svn.apache.org/viewvc?view=rev&revision=554070

>   public: virtual __thiscall bad_cast::~bad_cast(void)
>   public: virtual __thiscall bad_typeid::~bad_typeid(void)
>   public: virtual __thiscall exception::~exception(void)
>   public: class bad_cast & __thiscall bad_cast::operator=(class
bad_cast
> const &)
>   public: class bad_typeid & __thiscall bad_typeid::operator=(class
> bad_typeid const &)
>   public: class exception & __thiscall exception::operator=(class
> exception const &)
>   const exception::`vftable'

Again, no clue.

>   private: unsigned int __thiscall std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> >::_C_grow(unsigned
> int,unsigned int)const
>   private: unsigned int __thiscall std::basic_string<unsigned
> short,struct std::char_traits<unsigned short>,class
> std::allocator<unsigned short> >::_C_grow(unsigned int,unsigned
> int)const

I wonder if this is the culprit?
   http://svn.apache.org/viewvc?view=rev&revision=544975

>   private: int __thiscall std::basic_stringbuf<char,struct
> std::char_traits<char>,class std::allocator<char>
>> ::_C_grow(int,int)const
>   private: int __thiscall std::basic_stringbuf<unsigned short,struct
> std::char_traits<unsigned short>,class std::allocator<unsigned short>
>> ::_C_grow(int,int)const

This gratuitous incompatibility was introduced in:
   http://svn.apache.org/viewvc?view=rev&revision=380995

>   protected: int __thiscall std::basic_streambuf<char,struct
> std::char_traits<char> >::_C_putback_avail(void)const
>   protected: int __thiscall std::basic_streambuf<unsigned short,struct
> std::char_traits<unsigned short> >::_C_putback_avail(void)const

return type changed from streamsize to size_t (otherwise benign
and not detectable by UNIX compilers):
   http://svn.apache.org/viewvc?view=rev&revision=384278

>   protected: int __thiscall std::basic_stringbuf<char,struct
> std::char_traits<char>,class std::allocator<char>
>> ::_C_strlen(void)const
>   protected: int __thiscall std::basic_stringbuf<unsigned short,struct
> std::char_traits<unsigned short>,class std::allocator<unsigned short>
>> ::_C_strlen(void)const

Changed from protected to private (otherwise benign and not
detectable by UNIX compilers):
   http://svn.apache.org/viewvc?view=rev&revision=379032

>   protected: int __thiscall std::basic_streambuf<char,struct
> std::char_traits<char> >::_C_write_avail(void)const
>   protected: int __thiscall std::basic_streambuf<unsigned short,struct
> std::char_traits<unsigned short> >::_C_write_avail(void)const

Return type changed from streamsize to size_t otherwise benign
and not detectable by UNIX compilers):
   http://svn.apache.org/viewvc?view=rev&revision=384278

>   double const __rw::__rw_dbl_denorm_min
>   double const __rw::__rw_dbl_infinity
>   double const __rw::__rw_dbl_qNaN
>   double const __rw::__rw_dbl_sNaN
>   float const __rw::__rw_flt_denorm_min
>   float const __rw::__rw_flt_infinity
>   float const __rw::__rw_flt_qNaN
>   float const __rw::__rw_flt_sNaN
>   long double const __rw::__rw_ldbl_denorm_min
>   long double const __rw::__rw_ldbl_infinity
>   long double const __rw::__rw_ldbl_qNaN
>   long double const __rw::__rw_ldbl_sNaN

STDCXX-509

>   public: virtual char const * __thiscall exception::what(void)const
> 
> This concerns me quite a bit.

Yeah, it's not good. Most compilers tolerate most if not all of
these kinds of changes (template code, changing return type, etc.)
As always, Windows is a pain in the ass.

Mime
View raw message