Martin Sebor wrote:
> I've repeated the same test with both the library as well as
> the examples built with MSVC 7.1. The results are a lot better,
> although I still see an unsat for the exception copy ctor (as
> in the previous case):
>
> EXAMPLE
> ifstream.exe: exception::exception(const exeception&)
I accidentally overwrote the config macro patch when I rebuilt
the library. After I reapplied it (and rebuilt the lib) even
this unsat has gone away.
> I suspect the different results between the two runs (MSVC 7.1
> only amd MSVC 8.0/7.1) might be attributable to configuration
> differences between the two libraries. I.e., configuring the
> same version of stdcxx will produce different results with
> different versions of the same compiler (i.e., MSVC 7.1 and
> 8.0). Configuring a more recent version of stdcxx with a more
> recent version of MSVC will almost certainly yield different
> results than configuring an earlier version of the library
> with an older version of the compiler.
>
> This seems like a pretty fundamental problem with stdcxx, one
> that'll be very hard to avoid. The purpose of the configuration
> tests, i.e., to adjust the library to the compilation environment,
> is at odds with goal of providing binary compatibility...
>
> Martin Sebor wrote:
>> While testing the patch for the missing exception symbols I'm
>> running into a few other unsats that I haven't seen mentioned
>> before. I'm not sure if it's relevant yet but I'm linking
>> stdcxx 4.2.0 15d DLL built with MSVC 8.0 into 4.1.3 examples
>> built with MSVC 7.1 (also 15d).
>>
>> EXAMPLE UNSAT
>> codecvt1.exe: codecvt<char, char, mbstate_t>::id
>> ifstream.exe: exception something(*)
>> istringstream.exe ios::setstate(__rw_iostate)
>> stringstream.exe: std::string::length() const
>> wostream.exe wios::widen(char)
>>
>> Any ideas?
>>
>> [*] Btw., how do I demangle MSVC symbols? (I checked dumpbin
>> help but I don't see any obvious option).
>>
>> Martin
>
|