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
